1 |
Yes, I think this is a good idea, it would allow the dependencies to |
2 |
be expressed nicely as conditions. |
3 |
|
4 |
But I'm not sure how this would be a USE flag. It should behave like |
5 |
one during the build, but it would be best if it was not written into |
6 |
the VDB as such, at least in a way that would be considered by |
7 |
--newuse. It don't want "emerge -unD" on the booted system want to |
8 |
reinstall all packages because the current ones were cross-compiled. |
9 |
Does the test flag already behave nicely like that? In that case, all |
10 |
is good, and I can try to implement this. |
11 |
|
12 |
On a slightly different subject: I've been porting some packages to |
13 |
HDEPEND and I've seen problems with packages that want to use the |
14 |
programs they build during the build (or in postinst). Of couse this |
15 |
works for native builds, and it can be fixed to work for cross-compile |
16 |
builds (build native version or HDEPEND on host package). |
17 |
|
18 |
But what do we do with the strange case where ROOT!=/ but |
19 |
--crosscompile/FEATURES=crosscompile is not in affect? Can we expect |
20 |
that we will be able to run the programs that were built? What if they |
21 |
link to libraries only available in ROOT? |
22 |
|
23 |
So, I think it would make sense for a lot of packages to treat ROOT!=/ |
24 |
equivalently to cross-compilation, i.e. require host tool to be |
25 |
present. But with what has currently been proposed there is no |
26 |
conditional dependency on ROOT!=/, so a package cannot demand that a |
27 |
tool be present on the host. Then, it may be a good idea to add a |
28 |
conditional dependency on ROOT!=/. |
29 |
|
30 |
In fact, I think that --crosscompile or FEATURES=crosscompile could |
31 |
actually be abolished and only this condition would be available. It's |
32 |
true that some packages would only use the host dependency if there's |
33 |
actual cross-compilation going on, but nothing will break. This would |
34 |
ease configuration and reduce the number of cases to be tested. |
35 |
|
36 |
On Fri, Sep 21, 2012 at 6:06 PM, Zac Medico <zmedico@g.o> wrote: |
37 |
> On 09/20/2012 10:34 AM, Ambroz Bizjak wrote: |
38 |
>> The question now is, how should this method for checking |
39 |
>> --crosscompile be implemented? In particular, we have two options: |
40 |
>> |
41 |
>> - Environment variable. If so, how to call it? Possible names are |
42 |
>> CROSSCOMPILE, GENTOO_CROSSCOMPILE, PORTAGE_CROSSCOMPILE, |
43 |
>> ECROSSCOMPILE... For more generic names (CROSSCOMPILE) it needs to be |
44 |
>> taken into account that they may inadvertently affect packages. |
45 |
>> However environment vars have the benefit that it's easy to pass them |
46 |
>> through programs and scripts. |
47 |
>> |
48 |
>> - Internal function, similar to "use". Probably "is_crosscompile". |
49 |
>> This may look nicer and reduces the risk of collisions. |
50 |
> |
51 |
> Since it's just a boolean flag, we could have a special "crosscompile" |
52 |
> USE flag for this, so that the use() function could be used like we |
53 |
> currently use it for the "test" USE flag. The flag would be forced on or |
54 |
> off based on your configuration, similar to the "test" flag [1], so |
55 |
> there wouldn't be any danger of the flag being accidentally enabled or |
56 |
> disabled. The flag could be bound to FEATURES=crosscompile, or some |
57 |
> other package manager configuration variable. Note that if we add a |
58 |
> --crosscompile option to emerge, then we'll also have to add it to the |
59 |
> ebuid(1) command, so maybe it's better to forgo the commandline option |
60 |
> and just toggle it with a configuration variable like |
61 |
> FEATURES=crosscompile. Also, it's conceivable that you could drop the |
62 |
> CROSS_HDEPEND variable, in favor of HDEPEND="crosscompile? ( foo )" |
63 |
> syntax (somewhat in alignment with Brian Harring's DEPENDENCIES proposal). |
64 |
> |
65 |
> [1] https://bugs.gentoo.org/show_bug.cgi?id=373209 |
66 |
> -- |
67 |
> Thanks, |
68 |
> Zac |