On Wed, Dec 11, 2013 at 11:20 PM, Michał Górny wrote:
> Real life example first, pathological theories later.
As I stated before, I don't have a 100% real-life example as I've
found other workarounds in each case, as, clearly, has gx86, thus-far.
However, the problem pertains to any non-header-w
Dnia 2013-12-11, o godz. 23:10:12
Greg Turner napisał(a):
> Encouraging everyone to wrap headers, even, for example, in
> pathological cases where there is not, in fact, any header conflict
> between ABI's, to begin with, seems to me like incurring a cost
> (likelihood of broken autotools macros)
On Wed, Dec 11, 2013 at 10:33 PM, Michał Górny wrote:
>> Regardless, if our standard advice is "try not to use this automagic
>> header wrapping feature, it can break autoconf assumptions" (IIRC, it
>> is -- but if it isn't, it probably should be), then we ought to
>> provide /some/ convenient mea
Dnia 2013-12-11, o godz. 17:20:08
Greg Turner napisał(a):
> On Wed, Dec 11, 2013 at 1:37 PM, hasufell wrote:
> > On 12/11/2013 10:18 PM, Greg Turner wrote:
> >>
> >
> > this needs more explanation. Why do we want this?
>
> Sometimes the automagic header stuff is working against the ebuild
> aut
On Wed, Dec 11, 2013 at 1:37 PM, hasufell wrote:
> On 12/11/2013 10:18 PM, Greg Turner wrote:
>>
>
> this needs more explanation. Why do we want this?
Sometimes the automagic header stuff is working against the ebuild
author, or at least threatens to, in the future.
The most plausible etiology w
On 12/11/2013 10:18 PM, Greg Turner wrote:
>
this needs more explanation. Why do we want this?
Add a MULTILIB_INSECURE_INSTALL variable to eclass/multilib-minimal.eclass
Sometimes the "multilib magic header" business is an unwanted
feature. For example, it is infuriating to be forced
to wrap a header file (or, less offensively, but still quite
offensively, to be forced to implement inter-
