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 |