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
rationale seems especially true in this case, where nostrip and
debugging flags will do no harm for packages that aren't C or C++.
I tend to agree here on pragmatic principal as opposed to bowing to
"this is the ideal case" that some members of the portage team seem to
want. debug-build can always be expanded to turn on generic debugging
for other build systems and languages.
I realize it's not the "perfect solution." But no one has implemented a
better one. People only wait so long for things before getting fed up
and saying "it's going in anyway."
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.
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.)
We've discussed this multiple times, and it's always been the conclusion
that per package.env should go in bashrc, as bashrc is generally more
powerful than anything we could devise. The only downside afaik, for
bashrc is that you can't do per package FEATURES as FEATURES is a
python-side var. But you shouldn't need per package FEATURES by design;
FEATURES are for portage, not your ebuild.
-g2boojum-
--
gentoo-dev@gentoo.org mailing list
