On Wednesday 07 June 2006 16:10, Zac Medico wrote: > 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.
the package maintainer provides some sane defaults ... the idea is for the full configuration to be offloaded to the profiles > 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. ok ? so what's stopping it from being integrated ? people want it ;) -mike
pgpdKMt1pCthw.pgp
Description: PGP signature
