| 1 |
On Wed, Dec 11, 2013 at 1:37 PM, hasufell <hasufell@g.o> wrote: |
| 2 |
> On 12/11/2013 10:18 PM, Greg Turner wrote: |
| 3 |
>> |
| 4 |
> |
| 5 |
> this needs more explanation. Why do we want this? |
| 6 |
|
| 7 |
Sometimes the automagic header stuff is working against the ebuild |
| 8 |
author, or at least threatens to, in the future. |
| 9 |
|
| 10 |
The most plausible etiology would be: ABI "X" is going to generate |
| 11 |
header_x.h but ABI "Y" is going to generate header_y.h, or no header |
| 12 |
at all. An argument could certainly be made this this calls for |
| 13 |
either (a) a way to exempt a particular header from the header |
| 14 |
automagic -- not all of them or (b) a general exemption from |
| 15 |
ebuild-crashing, for headers that are present for a certain ABI but |
| 16 |
not in other ABI's. The only reason I didn't implement either of |
| 17 |
those (both of which are probably preferable to mine) is that it |
| 18 |
seemed nontrivial, and I'm lazy. |
| 19 |
|
| 20 |
Regardless, if our standard advice is "try not to use this automagic |
| 21 |
header wrapping feature, it can break autoconf assumptions" (IIRC, it |
| 22 |
is -- but if it isn't, it probably should be), then we ought to |
| 23 |
provide /some/ convenient means to get around it, other than sneaking |
| 24 |
those headers in through some kind of inter-abi back-door, in order to |
| 25 |
fake out the automagic (which is, effectively, what we require right |
| 26 |
now). |
| 27 |
|
| 28 |
FWIW, I'm pretty sure that thus far, every time I've thought, |
| 29 |
initially, that I needed this feature, I've ended up deciding I didn't |
| 30 |
need it, after all. |
| 31 |
|
| 32 |
-gmt |
Archives