| 1 |
Am Sonntag, 22. Juni 2014, 15:31:43 schrieb Rich Freeman: |
| 2 |
> On Sun, Jun 22, 2014 at 9:11 AM, Kent Fredric <kentfredric@×××××.com> wrote: |
| 3 |
> > On 23 June 2014 01:02, Duncan <1i5t5.duncan@×××.net> wrote: |
| 4 |
> >> The usual conditional for that is USE=custom-cflags or a similar variant |
| 5 |
[...] |
| 6 |
> > The problem with a USE flag here as such is the change this eclass makes |
| 7 |
> > affects >900 packages in dev-perl/ , and its not easy to casually |
| 8 |
> > determine which of those packages have any C bits where CFLAGS are even |
| 9 |
> > meaningful. |
| 10 |
> > |
| 11 |
> > Which would mean having >900 packages with a new IUSE value that did |
| 12 |
> > nothing for a majority of them. |
| 13 |
|
| 14 |
The numbers are even worse; the use flag would be added to ~1400 packages, and |
| 15 |
it would actually matter for only ~300. |
| 16 |
|
| 17 |
> Would it make more sense to move filtering (and thus the flag) to |
| 18 |
> packages that actually use it, instead of doing it in the eclass? By |
| 19 |
> the same logic you have >900 packages filtering CFLAGS when many of |
| 20 |
> them don't even use CFLAGS. |
| 21 |
|
| 22 |
Offhand I don't know any way how the eclass could "know" whether a perl |
| 23 |
package requires C building or not. Any heuristics would be a hack at best. It |
| 24 |
might even be preferable to manually add some variable to 300 packages in the |
| 25 |
ebuild (which then makes the eclass add a use-flag custom-cflags). |
| 26 |
i.e. |
| 27 |
|
| 28 |
PERL_CFLAGS_HANDLING=yes |
| 29 |
inherit perl-module |
| 30 |
|
| 31 |
-- |
| 32 |
|
| 33 |
Andreas K. Huettel |
| 34 |
Gentoo Linux developer |
| 35 |
dilfridge@g.o |
| 36 |
http://www.akhuettel.de/ |
Archives