10 thoughts on “Mailbox: about the debug USE flag

  1. And I have used the verb “emit” in the proper way. If you couldn’t tell, please re-read the article.

    Like

  2. You describe two different things here, and I would like to separate them and comment on each of them:1. Some useflags like “debug” or “doc” do not have a completely consistent meaning. One reason for this is that the meaning must essentially depend on the project and what upstream provides, and the other reason is that for many packages, these flags could be much more fine-grained, e.g. “doc” could be splitted in “user-doc”, “developer-doc”, “interface-doc”, and these in turn be subdivided into manpages, info, ascii-doc, pdf-doc, ps-doc, html-doc, …; similarly for “debug” which could be subdivided into several verbosity levels and some other measures you mention above. So in the absence of this diversity some default choice must be made, and probably the best default choice for “debug” is to follow upstreams experience with bug reports: In fact, when a user really needs “debug” he is usually about to contact upstream anyway. If the user can easily fine-tune it manually (like in the mentioned case of eix where he can manually add the debug-flags if he does not like the choice caused by the flag) the better. Of course, it is important that it is documented what the flag actually does.2. The relation between the choice of code-paths (e.g. omitting certain optimizations) and backtraces is in its nature two-sided: You are right that it can happen that for a different code path a problem does not appear or appears in a different manner. However, these situations are relatively rare, and moreover, also the information that this changes things is often useful for debugging. On the other hand, it can happen that the optimized program has such another structure that a backtrace is almost useless. Also this situation is relatively rare. So, in my experience, usually the choice is not important, but when it is, it is not possible to predict which is the “right” choice: I do not agree with your opinion that one choice is always better than the other.

    Like

  3. “I could write a whole post about how I would expect app-portage packages to be a notch over the rest of the tree, given that are packages written specifically for Gentoo, and should know and comply with the policies we set out for packages. The fact that at least two fails to do that, is a bad sign.”Being the current tools-portage lead, I would be interested in that post.Additionally, I would like to point out the following message that is still applicable today.http://archives.gentoo.org/…What I find interesting is that nobody has really taken me up on the open-ended offer to touch/fix/change stuff in the tools-portage herd. Which leads me to believe that very few developers are really interested in them. (The one exception to the above is idl0r who has joined the herd and actively working on gentoolkit-dev.)

    Like

  4. Paul, to be honest, as far as I can see it’s always third party packages that have problems. Am I wrong that eix is not part of the team’s work?

    Like

  5. You are correct for eix, that package does not belong to the herd. Although due to its popularity, if it quits having an active maintainer it will probably migrate to being in the herd.

    Like

  6. > I sincerely try my best to have both the upstream packaging and the ebuild abiding by this rule: > –enable-debug in feng adds some further debug messages, and adds function that fully free the resources before exiting (useful to remove false positives from valgrind),> while –disable-debug removes all of that and all the assertions.Mmm if I’m reading this correctly, it means there is a third state where you don’t specify –enable nor –disable and it results in assertions enabled but other debug stuff disabled? How do you express this with an USE flag that’s either enabled or disabled and never unspecified?

    Like

  7. I’ve come across one situation where I think it’s acceptable for the debug flag to mess with CFLAGS – to disable any special CFLAGS that the build system normally uses but may interfere with debugging information.For example, dev-util/codeblocks normally builds with -ffast-math, as the code is written specifically to work with it. With –enable-debug that flag isn’t used.I don’t have a problem with the debug flag dropping flags that the build system added in the first place. What do you think?

    Like

  8. Yes, sorry Ryan, I should have explicited that… I agree, in that case the debug USE flag is fine with playing with the flags.. it’s the one the _user_ asks for that shouldn’t be touched.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s