On Sun, Jun 22, 2014 at 9:11 AM, Kent Fredric <[email protected]> wrote: > On 23 June 2014 01:02, Duncan <[email protected]> wrote: >> >> >> The usual conditional for that is USE=custom-cflags or a similar variant >> like custom-optimization. See the firefox ebuilds, which use both. >> >> $ equery -N u firefox | grep custom >> - - custom-cflags : Build with user-specified CFLAGS (unsupported) >> + + custom-optimization : Fine-tune custom compiler optimizations (-Os, >> -O0, -O1, -O2, -O3) >> >> >> Generally, such USE flags are discouraged in gentoo, where honoring a >> user's CFLAGS, etc. and letting them keep the pieces if it comes to that >> is the norm. Where upstream refuses to support custom cflags, however, >> the USE flag solution seems to be an accepted at maintainer discretion. > > The problem with a USE flag here as such is the change this eclass makes > affects >900 packages in dev-perl/ , and its not easy to casually determine > which of those packages have any C bits where CFLAGS are even meaningful. > > Which would mean having >900 packages with a new IUSE value that did nothing > for a majority of them.
Would it make more sense to move filtering (and thus the flag) to packages that actually use it, instead of doing it in the eclass? By the same logic you have >900 packages filtering CFLAGS when many of them don't even use CFLAGS. I definitely wouldn't go the I_KNOW_WHAT_IM_DOING route for something like flag filtering on something like perl. Before you know it everybody will just stick it in their defaults and it will lose all usefulness. That should be reserved for things with are somewhat likely to seriously cripple the system in a manner that isn't easy to recover from. Or, perhaps do this in the eclass, but wait until a big perl upgrade or something to introduce the change so that everybody using emerge -N doesn't have to re-install all of perl unnecessarily. Not a pretty solution any which way, but neither is filtering flags at such a large scale. It would make much more sense to filter them when they're known to not work. Upstream isn't going to "support" Gentoo no matter what we do anyway (whatever support even means when you're not paying them). Rich
