public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] new helper: econf_build
@ 2011-10-13 23:48 Mike Frysinger
  2011-10-14  1:41 ` Alec Warner
  2011-10-14  7:08 ` Michael Haubenwallner
  0 siblings, 2 replies; 6+ messages in thread
From: Mike Frysinger @ 2011-10-13 23:48 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] new helper: econf_build
  2011-10-13 23:48 [gentoo-dev] new helper: econf_build Mike Frysinger
@ 2011-10-14  1:41 ` Alec Warner
  2011-10-14  2:01   ` Mike Frysinger
  2011-10-14  7:08 ` Michael Haubenwallner
  1 sibling, 1 reply; 6+ messages in thread
From: Alec Warner @ 2011-10-14  1:41 UTC (permalink / raw
  To: gentoo-dev

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
>



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] new helper: econf_build
  2011-10-14  1:41 ` Alec Warner
@ 2011-10-14  2:01   ` Mike Frysinger
  0 siblings, 0 replies; 6+ messages in thread
From: Mike Frysinger @ 2011-10-14  2:01 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: Text/Plain, Size: 620 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] new helper: econf_build
  2011-10-13 23:48 [gentoo-dev] new helper: econf_build Mike Frysinger
  2011-10-14  1:41 ` Alec Warner
@ 2011-10-14  7:08 ` Michael Haubenwallner
  2011-10-14 15:45   ` Mike Frysinger
  1 sibling, 1 reply; 6+ messages in thread
From: Michael Haubenwallner @ 2011-10-14  7:08 UTC (permalink / raw
  To: gentoo-dev


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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] new helper: econf_build
  2011-10-14  7:08 ` Michael Haubenwallner
@ 2011-10-14 15:45   ` Mike Frysinger
  2011-10-14 15:53     ` Michael Haubenwallner
  0 siblings, 1 reply; 6+ messages in thread
From: Mike Frysinger @ 2011-10-14 15:45 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: Text/Plain, Size: 1141 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [gentoo-dev] new helper: econf_build
  2011-10-14 15:45   ` Mike Frysinger
@ 2011-10-14 15:53     ` Michael Haubenwallner
  0 siblings, 0 replies; 6+ messages in thread
From: Michael Haubenwallner @ 2011-10-14 15:53 UTC (permalink / raw
  To: gentoo-dev


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



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-10-14 15:54 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-13 23:48 [gentoo-dev] new helper: econf_build Mike Frysinger
2011-10-14  1:41 ` Alec Warner
2011-10-14  2:01   ` Mike Frysinger
2011-10-14  7:08 ` Michael Haubenwallner
2011-10-14 15:45   ` Mike Frysinger
2011-10-14 15:53     ` Michael Haubenwallner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox