This eclass bit seems completely out of date since afair, it was to be used for some sort of gconf debugging. Nowadays it's just polluting use flag list of our packages and triggering a bunch of useless bugs due to automake throwing warning when it sees unrecognized options.
Ok so nowadays I'm plenty confused by how we handle use=debug in eclass and in ebuilds. There seem to a lot of contradictory statements in ebuilds and I'll hereby write a proposal for how I think we could make this feature of the eclass useful again for all of our ebuilds, this change, should it be accepted would of course be documement in lenght. So we currently have three kind of packages, those with multiple level of debugging (via use=debug), those with only one level of debugging (on/off), and those with debug nor behind a debug flag (no example on the top of my head though). First, it think it's a mistake (nowadays) that the eclass does not check for the existance of IUSE=debug in the ebuild has it induced the pain of all those QA bugs with stricter autoconf. Second: * for the simple on/off case, GCONF_DEBUG is expected to be left empty/unset or to special_value1 so we can simply use use_enable in eclass. * for the multi-state case, I propose GCONF_DEBUG should be set to the value that should be used for the USE="-debug" case or eventually to a contruct representing both values in case default is the same as what we would put for USE="-debug" * for the last case, having a special_value2 to GCONF_DEBUG should allow us to let the ebuild do its sauce I'm leaving out the migration aspect right now as I'm a bit tired now. Please comment.
Maybe an updated on this old issue after two years would be interesting to refresh what way we want to take for the near future. For now, looks like setting GCONF_DEBUG to either "yes" or "no" is preferred over simply not setting it at all :-/
Looks like this is the only current blocker for gnome2.eclass tracker... but now I don't know what is the way to go :S I would say: - GCONF_DEBUG now defaults to "yes", I would move to in_iuse usage (like done in other places) and handle it simply adding "debug" to IUSE properly. - Once previous is done, I would change the following: if use debug ; then G2CONF="--enable-debug=yes ${G2CONF}" fi to: if has in_iuse debug; then if grep -q "able-debug" ${ECONF_SOURCE:-.}/configure | grep -q "minimum" ; then if use debug; then G2CONF="--enable-debug=yes ${G2CONF}" else G2CONF="--enable-debug=minimum ${G2CONF}" fi else G2CONF="$(use_enable debug) ${G2CONF}" fi fi
My thoughts about this are as follow: GCONF_DEBUG was introduced in order to control whether or not gnome2.eclass should handle USE=debug the particular gnome macros use. The eclass previously handled all ebuilds with USE=debug whether or not it was about the gnome2 macros. FTR this macro behaves like this: * --enable-debug (yes/minimum/maximum) -> enables debug to a level that is not null * --disable-debug -> disable all debug but also disable g_assert and various other glib related runtime checks * defaults to yes which is the same as minimal (iirc) disable-debug is nice in that it makes software run faster (however we have no numbers about how much faster) but, on the other hand, it makes debugging much harder. We made the decision long ago that we should never turn off default glib sanity checks (g_assert & co). Based on the previous explanation, and with consideration to USE=debug being useful at all or not: 1 ========= I suggest we keep GCONF_DEBUG but consider switching it to default to no (that's why we preferred it to be set always). This will trigger a few rebuilds due to change at the eclass level for ebuilds that do not have GCONF_DEBUG set yet so I guess we will need a news item or we should seek and update those old ebuilds. Then we can start removing this variable on bumps when appropriate. 2 ========= We make gnome2.eclass always take care of this configure switch when the macro is detected, not allowing ebuild to change its behavior thus removing USE=debug and the eclass variable. If needs be, it can be documented that EXTRA_ECONF allows users to disable debug and package.env level or at portage hooks level. == If USE=debug is actually useless, I would vote for option 2, but I will live fine with option 1.
(In reply to comment #4) [...] > disable-debug is nice in that it makes software run faster (however we have > no numbers about how much faster) but, on the other hand, it makes debugging > much harder. > Maybe we could add a USE that people could turn on to completely disable debug (like "disable-debug", it could show a warning when enabled at build time). That USE would be turned off by default, but I still think would be interesting to have it configurable because I know a lot of cases of people that won't ever report a bug about a crash (because they even don't use bugzilla at all, they simply use their system and, if an important crash appears, I (admin) can always switch that USE flag off and run emerge -avuDN world, at the same time I rebuild packages with debugging symbols and co.). [...] > 1 ========= > > I suggest we keep GCONF_DEBUG but consider switching it to default to no > (that's why we preferred it to be set always). > I agree with changing default > This will trigger a few rebuilds due to change at the eclass level for > ebuilds that do not have GCONF_DEBUG set yet so I guess we will need a news > item or we should seek and update those old ebuilds. > > Then we can start removing this variable on bumps when appropriate. > What is the advantage of using GCONF_DEBUG for enabling it instead of simply add "debug" to IUSE? > 2 ========= > > We make gnome2.eclass always take care of this configure switch when the > macro is detected, When I suggested first change to eclass, I looked to use that macro, the problem is that seems that some packages don't use that even providing yes/no/minimum options (I looked to "dia" package for checking)
(In reply to comment #5) > Maybe we could add a USE that people could turn on to completely disable > debug (like "disable-debug", it could show a warning when enabled at build > time). That USE would be turned off by default, but I still think would be > interesting to have it configurable because I know a lot of cases of people > that won't ever report a bug about a crash (because they even don't use > bugzilla at all, they simply use their system and, if an important crash > appears, I (admin) can always switch that USE flag off and run emerge -avuDN > world, at the same time I rebuild packages with debugging symbols and co.). Without analysis on the eventual performance gain, I would not support making it optional at all because it would cause software to stop well before it hits some part of the code with unchecked pointers. I am sure leio could develop on that front. > > 1 ========= > > > > I suggest we keep GCONF_DEBUG but consider switching it to default to no > > (that's why we preferred it to be set always). > > I agree with changing default > > > This will trigger a few rebuilds due to change at the eclass level for > > ebuilds that do not have GCONF_DEBUG set yet so I guess we will need a news > > item or we should seek and update those old ebuilds. > > > > Then we can start removing this variable on bumps when appropriate. > > > > What is the advantage of using GCONF_DEBUG for enabling it instead of simply > add "debug" to IUSE? Avoids dealing with packages that have debug, but not via the gnome macro and make ciaran happy as well for a 0-cost given todays eclass. > > 2 ========= > > > > We make gnome2.eclass always take care of this configure switch when the > > macro is detected, > > When I suggested first change to eclass, I looked to use that macro, the > problem is that seems that some packages don't use that even providing > yes/no/minimum options (I looked to "dia" package for checking) Imho, we should not try to cover non well defined cases like that, it only opens up to potential misuse of the configure switch. It already is annoying enough when upstream (eg. clutter/gtk-doc) gets creative and changes the meaning of those macro. If that is necessary we should just submit patches to upstream encouraging them to use gnome-common provided macros.
I think with USE=-debug, it should be using whatever the packages default is. To achieve that, we just don't pass ANY --*-debug flag then. Which is how I believe this is or used to be. For many low-level gnome libraries such default used to be --enable-debug=minimum, which leaves on public API checks (the g_return_if_fail and g_return_val_if_fail kind). Then --enable-debug=yes would usually leave in internal debugging asserts, perhaps costly debug checks, etc; whereas --disable-debug == --enable-debug=no would disable even public API checks, which is highly discouraged and meant for perhaps just embedded systems that have consumers of this library that are tightly checked and known to not need these checks. Another reason we didn't pass anything with USE=-debug was that some packages didn't have this "minimum" logic and wouldn't be happy about --enable-debug=minimum and error or do the opposite we want. As debug is as a general rule default disabled (or minimum if available) we could adapt to that by just not passing anything for USE=-debug, and I believe this is a sound approach. If we were to make IUSE=debug handling in gnome2.eclass only based on that GCONF_DEBUG variable being declared yes before inheriting, then first we should check any gnome2 inheriting ebuilds (at least those that have IUSE=debug from ebuild if the logic is assumed to kick in only then), and then add GCONF_DEBUG to where it's meant to exist. In the end the eclass should probably add IUSE=debug on its own too when GCONF_DEBUG=yes I agree we shouldn't trigger just with in_iuse in the eclass.
And, what about simply dropping all "debugging" handling from eclass? The idea would be to rely on developers setting "debug" switch properly and we could add a qa warning to show messages with "--disable-debug" has been passed and the gnome macro is detected :/ What do you think?
Well, looks like that macro is being deprecated in favor of a different one from autoconf-archive :S https://bugzilla.gnome.org/show_bug.cgi?id=729403
Per: https://git.gnome.org/browse/gnome-common/commit/?id=f9073d5defa6f30bb8b364c3a56c53a60eb0b0dd Looks like the new macro is only playing with CFLAGS (and, then, we should always disable debug in that case :|)
(Thanks to Gilles for the reference, pasting it here to ensure we don't forget it) https://wiki.gnome.org/Projects/GnomeCommon/Migration
*** Bug 472092 has been marked as a duplicate of this bug. ***
I think we could finally try to fix this long standing issue with eapi6. Personally I would opt for dropping all the eclass logic and rely on people handling debug USE flag on a per ebuild basis. I wonder if there would be any way of ensuring people don't pass --disable-debug when the macro is used... but I also wonder about the status of that macro in current tarballs as last time I checked there were plenty of variations per tarball :S
As noticed in IRC by Gilles, upstream is also moving to AX_* macros and, then, we wouldn't need anymore all this debug handling Another point for killing it then for eapi6 I guess :)
It is a bit explained here: https://wiki.gnome.org/Projects/GnomeCommon/Migration And the new macro is: http://www.gnu.org/software/autoconf-archive/ax_check_enable_debug.html That, if I understand correctly, would lead to we always using default for releases (debug disabled) as other values will only mess with the CFLAGS, that is something we always try to avoid
[master dc527ce] gnome2.eclass/gnome2-utils.eclass: implement eapi6 support and take advantage of that for finally fixing many bugs/enhancements that were waiting for this (#571378) 2 files changed, 113 insertions(+), 47 deletions(-)
