Patchwork autotools.bbclass: update gnu-config files always

When recipe inherits autotools it gets do_configure defined. One of
things which are done is autoreconf so gnu-config files are updated to
latest OE version.

But some recipes use own do_configure due to hard edited configure
scripts or other reasons. We can edit those recipes one by one or can
trick them and provide update gnu-config files without using
autoreconf.

Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
---
 meta/classes/autotools.bbclass |    6 ++++++
 1 file changed, 6 insertions(+)

On Tue, 2012-10-09 at 22:01 +0200, Marcin Juszkiewicz wrote:
> When recipe inherits autotools it gets do_configure defined. One of
> things which are done is autoreconf so gnu-config files are updated to
> latest OE version.
> 
> But some recipes use own do_configure due to hard edited configure
> scripts or other reasons. We can edit those recipes one by one or can
> trick them and provide update gnu-config files without using
> autoreconf.
> 
> Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
> ---
>  meta/classes/autotools.bbclass |    6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
> index e4e034b..d0aad0d 100644
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -99,6 +99,12 @@ autotools_preconfigure() {
>  			mkdir ${B}
>  		fi
>  	fi
> +
> +	# 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 )
>  }
>  
>  autotools_postconfigure(){

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.

We could then trigger the above behaviour for recipes which disable
reautoconf?

Ideally, we should be able to reautoconf everything and we shouldn't
have exceptions at all.

The aim here is to make things more deterministic and make it clear
which code paths are being used where and why.

Cheers,

Richard

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.