Re: [gentoo-dev] debug/release builds extensions/clarification proposal

[Peter Volkov]

В Пнд, 01/12/2008 в 06:16 +0100, Maciej Mrozowski пишет:
> Currently handling debug/release builds is incoherent and misleading to say
> the least. We have got in Gentoo:

All that parts do their separate and quite a different work so I can't
say that it's incoherent (by idea at least).

> The drawbacks are as follows:
> - USE=debug is useless  when CFLAGS/LDFLAGS or FEATURES are not appropriate

USE=debug enables additional debug output or more assertions in the
code. It's hard to tell in advance in details what USE=debug does since
different packages enable different things. But generally it adds
additional code with -DDEBUG and this is independent of CFLAGS/LDFLAGS.
If you know packages where this is not true, fill bugs on them.

> - CFLAGS/LDFLAGS must be set globally when they are about to be "supported"
> - those who don't want to set them globally, they are forced to use (very
> flexible and great indeed) /etc/portage/env hack - which is undocumented and
> unsupported, because everything user set there, is not shown by emerge --info,
> thus bug reports from such machines  are not taken into consideration, as
> virtually everything that breaks can be there

This leads me to different conclusion. I was thinking about new portage
feature: emerge --info <pkg> . So to make portage show not only global
information but per-package either. In many cases this will simplify
analyzing of the problem.

> - too much choice leads to confusion

That's always true. But we use Gentoo because we enjoy our freedom to
choose... Rigth? :)

> Implementation is trivial - eclass would be responsible for handling USE=debug
> flag, when debug is set:
> - replace CFLAGS with CFLAGS_DEBUG, LDFLAGS with LDFLAGS_DEBUG and possibly
> others
> - replace FEATURES with FEATURES_DEBUG

USE flags should never change {C,LD}FLAGS or FEATURES as they are
different things and such relation between USE flags, {C,LD}FLAGS and/or
FEATURES will lead to even more confusion. (also there is complexity
Duncan told you about...)

Personally to get build with symbols I use a trivial wrapper around
emerge:

demerge() {
  env USE="debug" CFLAGS="-O2 -pipe -g -ggdb" PKGDIR="/vt/binpkg-debug" \
  FEATURES="buildpkg splitdebug collision-protect ccache noclean installsources" \
    emerge "$@"
}

and I use demerge whenever I need to debug package. I'm sure this is
just a quick hack which could be greatly improved to track which
packages are installed with or without symbols. But you got an idea:
such thing are better to do with separate, but very tiny and simple
wrappers.

P.S. I remember most of this was already discussed in this mailing list.
Try to search it and you'll find much more ideas and motivations.

-- 
Peter.