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

[Alec Warner]

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@g.o mailing list