[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] some multilib-minimal enhancements [2/6]: add frob for consumers to disable automag
From:       Greg Turner <gmt () malth ! us>
Date:       2013-12-13 5:14:51
Message-ID: CA+VB3NTr7NA+gz-Pe0HnHzFfTEYj9KWybjTak6hR3hLQG9pyPw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Dec 11, 2013 at 11:20 PM, Micha=C5=82 G=C3=B3rny <mgorny@gentoo.org=
> 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-wrapping solution to
a header conflict as defined by the header automagic.  Here's an only
partially-contrived example that I came up against, recently, when I
was hacking on mysql:

When compiling multi-abi mysql, I had things set up only to compile
the server portion for the best abi, and the client portion for every
abi.  This resulted in a situation where the header file generated
included a named-pipe file constant for the best ABI, but not for the
others; the header files were otherwise identical.  In fact, I managed
to solve that, by passing the named-pipe constant configuration
parameter to the non-best ABI's as well as the best ABI; however, what
if this simpler solution had not been available, for example, because
the constant was only applicable to the server build?

Then, I would have wanted to achieve the same effect, by using the
header generated for the best ABI for all of the ABI's, as the
presence of the constant would have had no detrimental effect on the
non-best ABI's, while it would have been required for the best-ABI on
the server-side.

Now, admittedly, we are drifting into a hypothetical case, but, I'd
say, a plausible one, likely to be similar to other cases that will
come up in future real-world situations.

How should I achieve the aforementioned result, assuming that my mysql
ebuild was based on multilib-minimal?

There are a number of ways, but perhaps the easiest would be to delete
the header file from each of the non-best ABI's before the header
automagic has the chance to run, while for the best ABI, instead of
deleting the header file, I stash it away somewhere in ${T} and then
restore it from ${T} during multilib_src_install_all.

While this solution works, note that I've had to jump through hoops to
prevent the header automagic feature from biting my ebuild in the
butt.  Mysql generates precisely the header file I want in the correct
moment, the best ABI installation phase, but I can't just leave it
there... instead, I must play a shell game where I hide it from the
header automagic and restore it afterwards, when the header automagic
isn't looking.

It's not a bug -- the header automagic and the mysql build system have
all performed their functions perfectly.  But it strongly suggests
that a misfeature exists, because we've forced the ebuild author to
play a shell game to deceive the header automagic framework that was
supposed to be doing them a favor.

This same misfeature exists in any case where the header automagic
insists that an identical header must be installed by all ABI's when,
in fact, we have found some better solution than header-wrapping.  As
I've already stated, the identical problem even exists in the case
that a header only gets generated for a single ABI, in which case,
there isn't even a conflict between the ABI's at all.  It would also
exist if, for example, the build script generated a high-resolution
build time specifier in a header somewhere... I could invent any
number of scenarios but the long and the short of it is, the header
wrapping feature is supposed to be an option to solve a conflict, not
a requirement -- yet we've provided no elegant, easy-to-use
alternative.

-gmt

[prev in list] [next in list] [prev in thread] [next in thread]