W dniu 10.10.2012 00:34, Richard Purdie pisze:
> On Tue, 2012-10-09 at 22:01 +0200, Marcin Juszkiewicz wrote:
>> + # not all recipes which use autotools use it's do_configure
>> + ( for ac in `find ${S} -name configure.in -o -name configure.ac`; do
>> + install -m 0755
>> ${STAGING_DATADIR_NATIVE}/gnu-config/config.guess `dirname $ac`
>> + install -m 0755 ${STAGING_DATADIR_NATIVE}/gnu-config/config.sub
>> `dirname $ac`
>> + done )
> I'm not sure we want to go down this route. How about we mandate that
> everything call autotools_do_configure but allow various sections of it
> to be optional depending on some variables.
How would we support ncurses then? It runs configure in different ways
due to ENABLE_WIDEC variable (some play with EXTRA_OECONF maybe).
Or slang which has ${S}/autoconf/configure.ac when autotools.bbclass
checks only for ${S}/configure.{in,ac} when it decides to run autoreconf?
db one is easier as there we can add some variable like SKIP_AUTORECONF
and it should work. Similar with xinetd.
> We could then trigger the above behaviour for recipes which disable
> reautoconf?
That's an option. But we need also something for situations like
slang/ncurses.
> Ideally, we should be able to reautoconf everything and we shouldn't
> have exceptions at all.
And no reset for PARALLEL_MAKE as well. But we learnt during those OE
years that there is no such thing as ideal situation.
> The aim here is to make things more deterministic and make it clear
> which code paths are being used where and why.
Agree.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
