1 |
On 09/21/2012 06:06 PM, Zac Medico wrote: |
2 |
> On 09/20/2012 10:34 AM, Ambroz Bizjak wrote: |
3 |
>> The question now is, how should this method for checking |
4 |
>> --crosscompile be implemented? In particular, we have two options: |
5 |
>> |
6 |
>> - Environment variable. If so, how to call it? Possible names are |
7 |
>> CROSSCOMPILE, GENTOO_CROSSCOMPILE, PORTAGE_CROSSCOMPILE, |
8 |
>> ECROSSCOMPILE... For more generic names (CROSSCOMPILE) it needs to be |
9 |
>> taken into account that they may inadvertently affect packages. |
10 |
>> However environment vars have the benefit that it's easy to pass them |
11 |
>> through programs and scripts. |
12 |
>> |
13 |
>> - Internal function, similar to "use". Probably "is_crosscompile". |
14 |
>> This may look nicer and reduces the risk of collisions. |
15 |
> |
16 |
> Since it's just a boolean flag, we could have a special "crosscompile" |
17 |
> USE flag for this, so that the use() function could be used like we |
18 |
> currently use it for the "test" USE flag. The flag would be forced on or |
19 |
> off based on your configuration, similar to the "test" flag [1], so |
20 |
> there wouldn't be any danger of the flag being accidentally enabled or |
21 |
> disabled. The flag could be bound to FEATURES=crosscompile, or some |
22 |
> other package manager configuration variable. Note that if we add a |
23 |
> --crosscompile option to emerge, then we'll also have to add it to the |
24 |
> ebuid(1) command, so maybe it's better to forgo the commandline option |
25 |
> and just toggle it with a configuration variable like |
26 |
> FEATURES=crosscompile. Also, it's conceivable that you could drop the |
27 |
> CROSS_HDEPEND variable, in favor of HDEPEND="crosscompile? ( foo )" |
28 |
> syntax (somewhat in alignment with Brian Harring's DEPENDENCIES proposal). |
29 |
> |
30 |
> [1] https://bugs.gentoo.org/show_bug.cgi?id=373209 |
31 |
> |
32 |
|
33 |
|
34 |
I like the idea. |
35 |
|
36 |
lu |