1 |
On Thu, Oct 13, 2011 at 4:48 PM, Mike Frysinger <vapier@g.o> wrote: |
2 |
> i've found myself a few times having to implement logic like so: |
3 |
> CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \ |
4 |
> CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \ |
5 |
> CPPFLAGS=${BUILD_CPPFLAGS} \ |
6 |
> LDFLAGS=${BUILD_LDFLAGS} \ |
7 |
> CC=$(tc-getBUILD_CC) \ |
8 |
> LD=$(tc-getBUILD_LD) \ |
9 |
> econf --host=${CBUILD} "$@" |
10 |
|
11 |
I'm a newb, are BUILD_* expected to be set by users? |
12 |
|
13 |
-A |
14 |
|
15 |
> |
16 |
> this is to deal with packages that build up not insignificant (let's call them |
17 |
> "nificant") binaries which are then used at build time. when cross-compiling, |
18 |
> you can't execute those binaries, and things fail. |
19 |
> |
20 |
> python is a good example. it builds up the local python interpreter (which is |
21 |
> all written in C/etc...), and then uses that to parse local python scripts |
22 |
> which take care of building everything else. so a while ago we added code so |
23 |
> that it'd build two python binaries when cross-compiling: a local ${CBUILD} |
24 |
> version which is then used to parse the python build files to compile for |
25 |
> ${CHOST}. using host python won't work if it's newer/older/insane/afk. |
26 |
> |
27 |
> ncurses compiles its local term database by first creating a tic helper and |
28 |
> then parsing its local files. we can't use the build system's tic because if |
29 |
> the installed ncurses is a different version, we run into fun things like |
30 |
> crashes/infinite loops/etc... |
31 |
> |
32 |
> the latest thing i hit was elfutils where it creates a local binary to |
33 |
> generate a database of headers which it then compiles into the target code. |
34 |
> |
35 |
> so rather than continuing to copy & paste this logic everywhere, i'm going to |
36 |
> add it to toolchain-funcs.eclass as "econf_build". any feedback before i do ? |
37 |
> -mike |
38 |
> |