| 1 |
On Wed, Dec 11, 2013 at 10:33 PM, Michał Górny <mgorny@g.o> wrote: |
| 2 |
>> Regardless, if our standard advice is "try not to use this automagic |
| 3 |
>> header wrapping feature, it can break autoconf assumptions" (IIRC, it |
| 4 |
>> is -- but if it isn't, it probably should be), then we ought to |
| 5 |
>> provide /some/ convenient means to get around it, other than sneaking |
| 6 |
>> those headers in through some kind of inter-abi back-door, in order to |
| 7 |
>> fake out the automagic (which is, effectively, what we require right |
| 8 |
>> now). |
| 9 |
> |
| 10 |
> The advice tells to do things properly, not to choose even worse |
| 11 |
> solution. If wrapping breaks something, random header install is going |
| 12 |
> to screw up even worse. |
| 13 |
|
| 14 |
The matter of whether ebuild authors know how to implement multilib |
| 15 |
headers correctly or not is mostly orthogonal to that of whether or |
| 16 |
not multilib-minimal.eclass throws up obstructions in the way of a |
| 17 |
correct (or incorrect) implementation. I'm attempting to address the |
| 18 |
latter issue, not the former. |
| 19 |
|
| 20 |
Encouraging everyone to wrap headers, even, for example, in |
| 21 |
pathological cases where there is not, in fact, any header conflict |
| 22 |
between ABI's, to begin with, seems to me like incurring a cost |
| 23 |
(likelihood of broken autotools macros) with no benefit, I can |
| 24 |
identify, to end-users. |
| 25 |
|
| 26 |
Furthermore, the possibility of a superior, but more involved and |
| 27 |
hypothetical solution to a problem is, in my experience, not always a |
| 28 |
good reason to avoid a quick and simple solution, available |
| 29 |
immediately. If you prefer that I code up one of the more |
| 30 |
sophisticated approaches I mentioned, I'd be happy and perfectly |
| 31 |
capable to do so, just let me know which you prefer. |
| 32 |
|
| 33 |
-gmt |
Archives