FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-13-2011, 11:48 PM
Mike Frysinger
 
Default new helper: econf_build

i've found myself a few times having to implement logic like so:
CFLAGS=${BUILD_CFLAGS:--O1 -pipe}
CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe}
CPPFLAGS=${BUILD_CPPFLAGS}
LDFLAGS=${BUILD_LDFLAGS}
CC=$(tc-getBUILD_CC)
LD=$(tc-getBUILD_LD)
econf --host=${CBUILD} "$@"

this is to deal with packages that build up not insignificant (let's call them
"nificant") binaries which are then used at build time. when cross-compiling,
you can't execute those binaries, and things fail.

python is a good example. it builds up the local python interpreter (which is
all written in C/etc...), and then uses that to parse local python scripts
which take care of building everything else. so a while ago we added code so
that it'd build two python binaries when cross-compiling: a local ${CBUILD}
version which is then used to parse the python build files to compile for
${CHOST}. using host python won't work if it's newer/older/insane/afk.

ncurses compiles its local term database by first creating a tic helper and
then parsing its local files. we can't use the build system's tic because if
the installed ncurses is a different version, we run into fun things like
crashes/infinite loops/etc...

the latest thing i hit was elfutils where it creates a local binary to
generate a database of headers which it then compiles into the target code.

so rather than continuing to copy & paste this logic everywhere, i'm going to
add it to toolchain-funcs.eclass as "econf_build". any feedback before i do ?
-mike
 
Old 10-14-2011, 01:41 AM
Alec Warner
 
Default new helper: econf_build

On Thu, Oct 13, 2011 at 4:48 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> i've found myself a few times having to implement logic like so:
> * * * *CFLAGS=${BUILD_CFLAGS:--O1 -pipe}
> * * * *CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe}
> * * * *CPPFLAGS=${BUILD_CPPFLAGS}
> * * * *LDFLAGS=${BUILD_LDFLAGS}
> * * * *CC=$(tc-getBUILD_CC)
> * * * *LD=$(tc-getBUILD_LD)
> * * * *econf --host=${CBUILD} "$@"

I'm a newb, are BUILD_* expected to be set by users?

-A

>
> this is to deal with packages that build up not insignificant (let's call them
> "nificant") binaries which are then used at build time. *when cross-compiling,
> you can't execute those binaries, and things fail.
>
> python is a good example. *it builds up the local python interpreter (which is
> all written in C/etc...), and then uses that to parse local python scripts
> which take care of building everything else. *so a while ago we added code so
> that it'd build two python binaries when cross-compiling: a local ${CBUILD}
> version which is then used to parse the python build files to compile for
> ${CHOST}. *using host python won't work if it's newer/older/insane/afk.
>
> ncurses compiles its local term database by first creating a tic helper and
> then parsing its local files. *we can't use the build system's tic because if
> the installed ncurses is a different version, we run into fun things like
> crashes/infinite loops/etc...
>
> the latest thing i hit was elfutils where it creates a local binary to
> generate a database of headers which it then compiles into the target code.
>
> so rather than continuing to copy & paste this logic everywhere, i'm going to
> add it to toolchain-funcs.eclass as "econf_build". *any feedback before i do ?
> -mike
>
 
Old 10-14-2011, 02:01 AM
Mike Frysinger
 
Default new helper: econf_build

On Thursday 13 October 2011 21:41:02 Alec Warner wrote:
> On Thu, Oct 13, 2011 at 4:48 PM, Mike Frysinger wrote:
> > i've found myself a few times having to implement logic like so:
> > CFLAGS=${BUILD_CFLAGS:--O1 -pipe}
> > CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe}
> > CPPFLAGS=${BUILD_CPPFLAGS}
> > LDFLAGS=${BUILD_LDFLAGS}
> > CC=$(tc-getBUILD_CC)
> > LD=$(tc-getBUILD_LD)
> > econf --host=${CBUILD} "$@"
>
> I'm a newb, are BUILD_* expected to be set by users?

yes & no. toolchain-funcs is intelligent to setup sane values if need be.
-mike
 
Old 10-14-2011, 07:08 AM
Michael Haubenwallner
 
Default new helper: econf_build

On 10/14/11 01:48, Mike Frysinger wrote:
> i've found myself a few times having to implement logic like so:
> CFLAGS=${BUILD_CFLAGS:--O1 -pipe}
> CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe}
> CPPFLAGS=${BUILD_CPPFLAGS}
> LDFLAGS=${BUILD_LDFLAGS}
> CC=$(tc-getBUILD_CC)
> LD=$(tc-getBUILD_LD)
> econf --host=${CBUILD} "$@"
>
<snip>
> so rather than continuing to copy & paste this logic everywhere, i'm going to
> add it to toolchain-funcs.eclass as "econf_build". any feedback before i do ?

Eventually not to stick to 'econf', but provide a more generic one,
so it is useable like this (in lack of a better name):

run_with_build_env econf --host=${CBUILD} ...

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 
Old 10-14-2011, 03:45 PM
Mike Frysinger
 
Default new helper: econf_build

On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote:
> On 10/14/11 01:48, Mike Frysinger wrote:
> > i've found myself a few times having to implement logic like so:
> > CFLAGS=${BUILD_CFLAGS:--O1 -pipe}
> > CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe}
> > CPPFLAGS=${BUILD_CPPFLAGS}
> > LDFLAGS=${BUILD_LDFLAGS}
> > CC=$(tc-getBUILD_CC)
> > LD=$(tc-getBUILD_LD)
> > econf --host=${CBUILD} "$@"
>
> <snip>
>
> > so rather than continuing to copy & paste this logic everywhere, i'm
> > going to add it to toolchain-funcs.eclass as "econf_build". any
> > feedback before i do ?
>
> Eventually not to stick to 'econf', but provide a more generic one,
> so it is useable like this (in lack of a better name):
>
> run_with_build_env econf --host=${CBUILD} ...

i thought of that, but it seems like we've generally moved away from this
style in the tree. the biggest example being `try ...` -> `... || die`.

i'll probably implement as an @INTERNAL:
tc-env_build() { ... }

then define econf_build on top of that as an exported API. then let's see what
grows organically beyond.
-mike
 
Old 10-14-2011, 03:53 PM
Michael Haubenwallner
 
Default new helper: econf_build

On 10/14/11 17:45, Mike Frysinger wrote:
> On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote:
>> On 10/14/11 01:48, Mike Frysinger wrote:
>>> i've found myself a few times having to implement logic like so:
>>> CFLAGS=${BUILD_CFLAGS:--O1 -pipe}
>>> CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe}
>>> CPPFLAGS=${BUILD_CPPFLAGS}
>>> LDFLAGS=${BUILD_LDFLAGS}
>>> CC=$(tc-getBUILD_CC)
>>> LD=$(tc-getBUILD_LD)
>>> econf --host=${CBUILD} "$@"
>>
>> <snip>

> i'll probably implement as an @INTERNAL:
> tc-env_build() { ... }
>
> then define econf_build on top of that as an exported API. then let's see what
> grows organically beyond.

Fine with me.

/haubi/
--
Michael Haubenwallner
Gentoo on a different level
 

Thread Tools




All times are GMT. The time now is 11:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org