-----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@gentoo.org mailing list
