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

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

Zac, I think you misunderstood me here. Crosscompile-only HDEPEND is
definitely necessary, I've seen many packages need this. But what I'm
suggesting is that we also, and maybe only, need "ROOT != /" - only
HDEPEND dependencies. This means that the dependency would only be
required if the package is being built for a ROOT that is not /. The
idea is to eliminate the strange case that is ROOT!=/ but FEATURES has
no crosscompile. If the package requires tools that it would build
itself if ROOT was /, it will use the host's version of the tool
whenever ROOT!=/  It wouldn't have to worry about whether the tools it
builds link to libraries in ROOT.

So my proposal is basically, instead of:
HDEPEND="crosscompile? ( ~${CATEGORY}/${P} )    (yes, that seems to be
the most common case)

there would also, and maybe only, be:
HDEPEND="root_not_slash? ( ~${CATEGORY}/${P} )"

root_not_slash (or another name) would essentially be a superset of
crosscompile, since crosscompile implies ROOT!=/.

P.S. sorry Zac I sent you this twice, damn GMail :)

On Sat, Sep 22, 2012 at 6:31 PM, Zac Medico <zmedico@gentoo.org> wrote:
> On 09/22/2012 09:08 AM, Ambroz Bizjak wrote:
> > 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.
> 
> Simply add your special flag to the _feature_flags variable in
> config.py, and it will be exempt from --newuse. See this commit:
> 
> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=6b19f71b39b6af43307abf20654511bace041217
>  
> > 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!=/.
> 
> If I understand correctly, that would be like a CROSS_TDEPEND? If we
> translate that to a conditional, it would become DEPEND="crosscompile? (
> foo )", since our plan was to make DEPEND apply to ROOT!=/ and HDEPEND
> apply to ROOT=/, right?
> 
> > 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.
> 
> Yeah, the split between HDEPEND and DEPEND might be enough so that you
> don't need these conditionals. If you're not really sure that the
> conditionals are needed, then maybe it's better to eliminate them for now.
> --
> Thanks,
> Zac


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