1 |
On Friday 14 October 2011 03:08:14 Michael Haubenwallner wrote: |
2 |
> On 10/14/11 01:48, Mike Frysinger wrote: |
3 |
> > i've found myself a few times having to implement logic like so: |
4 |
> > CFLAGS=${BUILD_CFLAGS:--O1 -pipe} \ |
5 |
> > CXXFLAGS=${BUILD_CXXFLAGS:--O1 -pipe} \ |
6 |
> > CPPFLAGS=${BUILD_CPPFLAGS} \ |
7 |
> > LDFLAGS=${BUILD_LDFLAGS} \ |
8 |
> > CC=$(tc-getBUILD_CC) \ |
9 |
> > LD=$(tc-getBUILD_LD) \ |
10 |
> > econf --host=${CBUILD} "$@" |
11 |
> |
12 |
> <snip> |
13 |
> |
14 |
> > so rather than continuing to copy & paste this logic everywhere, i'm |
15 |
> > going to add it to toolchain-funcs.eclass as "econf_build". any |
16 |
> > feedback before i do ? |
17 |
> |
18 |
> Eventually not to stick to 'econf', but provide a more generic one, |
19 |
> so it is useable like this (in lack of a better name): |
20 |
> |
21 |
> run_with_build_env econf --host=${CBUILD} ... |
22 |
|
23 |
i thought of that, but it seems like we've generally moved away from this |
24 |
style in the tree. the biggest example being `try ...` -> `... || die`. |
25 |
|
26 |
i'll probably implement as an @INTERNAL: |
27 |
tc-env_build() { ... } |
28 |
|
29 |
then define econf_build on top of that as an exported API. then let's see what |
30 |
grows organically beyond. |
31 |
-mike |