On Monday 01 of December 2008 09:36:12 Diego 'Flameeyes' Pettenò wrote: > > - USE=debug is useless when CFLAGS/LDFLAGS or FEATURES are not > > appropriate > What are you saying here? I'm afraid you're mistaken here.
The point is to look at this from users' (well, a bit) point of view -
USE=debug variable is ambiguous in it's meaning. While it enables only
codepaths (asserts, #ifdefs and similar) it suggests (by name and for some
packages not only suggests) enabling debug symbols.
And policy is to enforce CFLAGS from make.conf and wipe out every package-
defined flags as far as I know.
> For the most part, USE=debug means "enable debug code paths", which for
> lots of projects simply means "enable assertions"; there are packages
> that take this as "enable debug symbols too" but I don't think that's
> very valid since users might want debug code paths but not symbols and
> vice-versa (I indeed have debug symbols bug no debug codepaths enabled).
That's correct, the problem is - Gentoo does not provide officially supported
mechanism of enabling both or just debug symbols per package basis - it
doesn't even provide any supported/documented mechanism for per package
CFLAGS, FEATURES and similar.
If /etc/portage/env hack/feature could be made official (for CFLAGS,LDFLAGS
and bash-domain FEATURES) - it could address this issue good enough, because
with proper smart combination of symlinks/files the "ultimate configuration"
power would be delivered, not just "cleaning/workaround" I am actually
proposing. Per package debug/release/profile/or_any_other configuration is
what I would pursue, and in my proposal I used USE=debug as existing and
supported way of achieving this.
While I don't like hack @pve uses (I prefer portage/env as more convenient
way), his idea about emerge --info <pkg> seems interesting.
> - -ggdb *does not have any runtime performance hit*; neither in
Yes, I'm well aware of that, though it increases disk space requirements a bit
as it's applied to all libs/bins.
> - -O0 is not always a good idea; beside bugs in packages concealed by
> -O1+ [1]
[1] is a pathology and should be fought against, -O1+ may leave frame stack
useless for debugging due to inline optimizations in some places (especially
debugging inline class implementations is limited, which affects Qt/KDE) -
besides - I may not stated it clear - those default values would be defined in
the very same make.conf, so it could be:
CHOST="x86_64-pc-linux-gnu"
CFLAGS="-march=nocona -O2 -pipe -msse3 -ftree-vectorize"
CXXFLAGS="${CFLAGS}"
CFLAGS_DEBUG="-O2 -ggdb"
Yet, I still cannot think of this proposal other way like of dirty workaround
for the problem, that doesn't really exist (well, at least for developers, who
have meta-distribution and ultimate freedom for user in mind). For the users
the problem is real, of course it's usually a consequence of either not being
aware of those mechanisms or as a result of ambiguous semantics of USE=debug.
And what about pushing some bash-domain FEATURES to USE flags? Like nostrip,
splitdebug? I guess being able to set it per package is important.
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
