1 |
On Wed, Dec 11, 2013 at 11:20 PM, Michał Górny <mgorny@g.o> wrote: |
2 |
> Real life example first, pathological theories later. |
3 |
|
4 |
As I stated before, I don't have a 100% real-life example as I've |
5 |
found other workarounds in each case, as, clearly, has gx86, thus-far. |
6 |
However, the problem pertains to any non-header-wrapping solution to |
7 |
a header conflict as defined by the header automagic. Here's an only |
8 |
partially-contrived example that I came up against, recently, when I |
9 |
was hacking on mysql: |
10 |
|
11 |
When compiling multi-abi mysql, I had things set up only to compile |
12 |
the server portion for the best abi, and the client portion for every |
13 |
abi. This resulted in a situation where the header file generated |
14 |
included a named-pipe file constant for the best ABI, but not for the |
15 |
others; the header files were otherwise identical. In fact, I managed |
16 |
to solve that, by passing the named-pipe constant configuration |
17 |
parameter to the non-best ABI's as well as the best ABI; however, what |
18 |
if this simpler solution had not been available, for example, because |
19 |
the constant was only applicable to the server build? |
20 |
|
21 |
Then, I would have wanted to achieve the same effect, by using the |
22 |
header generated for the best ABI for all of the ABI's, as the |
23 |
presence of the constant would have had no detrimental effect on the |
24 |
non-best ABI's, while it would have been required for the best-ABI on |
25 |
the server-side. |
26 |
|
27 |
Now, admittedly, we are drifting into a hypothetical case, but, I'd |
28 |
say, a plausible one, likely to be similar to other cases that will |
29 |
come up in future real-world situations. |
30 |
|
31 |
How should I achieve the aforementioned result, assuming that my mysql |
32 |
ebuild was based on multilib-minimal? |
33 |
|
34 |
There are a number of ways, but perhaps the easiest would be to delete |
35 |
the header file from each of the non-best ABI's before the header |
36 |
automagic has the chance to run, while for the best ABI, instead of |
37 |
deleting the header file, I stash it away somewhere in ${T} and then |
38 |
restore it from ${T} during multilib_src_install_all. |
39 |
|
40 |
While this solution works, note that I've had to jump through hoops to |
41 |
prevent the header automagic feature from biting my ebuild in the |
42 |
butt. Mysql generates precisely the header file I want in the correct |
43 |
moment, the best ABI installation phase, but I can't just leave it |
44 |
there... instead, I must play a shell game where I hide it from the |
45 |
header automagic and restore it afterwards, when the header automagic |
46 |
isn't looking. |
47 |
|
48 |
It's not a bug -- the header automagic and the mysql build system have |
49 |
all performed their functions perfectly. But it strongly suggests |
50 |
that a misfeature exists, because we've forced the ebuild author to |
51 |
play a shell game to deceive the header automagic framework that was |
52 |
supposed to be doing them a favor. |
53 |
|
54 |
This same misfeature exists in any case where the header automagic |
55 |
insists that an identical header must be installed by all ABI's when, |
56 |
in fact, we have found some better solution than header-wrapping. As |
57 |
I've already stated, the identical problem even exists in the case |
58 |
that a header only gets generated for a single ABI, in which case, |
59 |
there isn't even a conflict between the ABI's at all. It would also |
60 |
exist if, for example, the build script generated a high-resolution |
61 |
build time specifier in a header somewhere... I could invent any |
62 |
number of scenarios but the long and the short of it is, the header |
63 |
wrapping feature is supposed to be an option to solve a conflict, not |
64 |
a requirement -- yet we've provided no elegant, easy-to-use |
65 |
alternative. |
66 |
|
67 |
-gmt |