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