Re: [gentoo-dev] 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} "$@" >> >> > 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
Re: [gentoo-dev] 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} "$@" > > > > > 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] 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} "$@" > > 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
Re: [gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] new helper: econf_build
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? -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 >
[gentoo-dev] 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 signature.asc Description: This is a digitally signed message part.