Re: [gentoo-dev] new helper: econf_build

[Alec Warner <antarus@gentoo.org>]

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
>