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

List:       gentoo-dev
Subject:    Re: [gentoo-dev] RFC: method of checking for cross compilation from ebuild functions
From:       Ambroz Bizjak <ambrop7 () gmail ! com>
Date:       2012-09-22 16:08:54
Message-ID: CAOA3yKKTY4BhubSd1UWCY4VDy7QY5W1pz8ke4UTjo3_V7YkGjw () mail ! gmail ! com
[Download RAW message or body]

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 <zmedico@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

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