Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Grant Goodyear wrote:
> Zac Medico wrote: [Wed Jun 07 2006, 01:30:38PM CDT]
>> Mike Frysinger wrote:
>>> this is a *huge* con ... developers are lazy, *i'm* lazy ... i
>>> certainly do not want to go through every single package i maintain
>>> and add 'debug-build' to IUSE or 'inherit some-new-eclass'
>> Sometimes it takes a little extra work to do things right, but
>> hopefully it will pay off in the long run.  A poor design decision
>> made now can haunt us for years to come.
>
> A "little extra work"?  I'm pretty sure that such an eclass would be
> required for better than half the tree (every package that contains some
> C or C++).  If almost everybody has to add the same piece of
> boilerplate to their ebuilds, then perhaps a sane package manager should
> be able to figure out what to do without the boilerplate.  That

It's a slippery slope when we start to incorporate special cases like that into a generic package manager.  Where does it end?  The same argument could be made again and again to add more special cases that further pollute the package manager.  We already have a standard solution for cases such as this, and that is to share the specialized functionality via an eclass.

> rationale seems especially true in this case, where nostrip and
> debugging flags will do no harm for packages that aren't C or C++.
>>> if the large majority of packages are going to be taking advantage of a
>>> feature, isnt the logical thing to opt everyone in rather than forcing the
>>> majority to opt themselves in ?
>> It really depends on the pros/cons applying something on a *global*
>> scale, like you propose.  A package manager (such as portage) will
>> never be able to make debug-build decisions that work well for *every*
>> ebuild.  That's why it's better for ebuilds to make those decisions
>> themselves (with the help of eclasses).
>
> I would think that your argument would depend on the probability of a
> package being an exception to the general rule.  How many packages
> actually fail to do what is expected when compiled with -g and nostrip
> (noting that those cases without binaries to strip don't count)?
> Unless that percentage is significant, then I would think that a simple
> solution that handles the common case is a very good thing.

Again, it's a slippery slope...

> Wouldn't the "simple" solution be to have package.* files that allow the
> user to specify FEATURES, CFLAGS, and CXXFLAGS per package?  (Of course,
> I do realize that it's the lack of such files that lead vapier to
> propose his solution, which is rather more convenient for one-off
> builds.)

Well, I'd say that per-package environment variables would be a better way to implement per-package CFLAGS, CXXFLAGS, etc.. There is a patch attached to bug 44796 that implements this.  Note that the debug-build.bashrc attached to my last post actually allows per-package debug-build via package.use.

Zac

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEhzK3/ejvha5XGaMRAufAAKDm2l8429xS14uPjbYV7Ky5dlFGHgCggXXH
rBVkHEMCcJZflR13vA26kog=
=DXg0
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list