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} $@
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
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} $@
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
signature.asc
Description: This is a digitally signed message part.
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} $@
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
[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.
Re: [gentoo-dev] new helper: econf_build
On Thu, Oct 13, 2011 at 4:48 PM, Mike Frysinger vap...@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
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.
