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