[Rpm-maint] [draft] spec file unification: autotools based projects

[Marc Haisenko]

On Friday 18 July 2008, Stanislav Brabec wrote:
> Autotools, distributions and processors are developing. Older autotools
> cannot detect processors and systems, that did not exist in time of the
> release. For example, old autotools were often not able to build shared
> s390/s390x libraries. Working with engineering samples could make
> autoreconf mandatory as well.

... or detect "armeb" as machine name big endian ARM processors. I regularly 
run into this. And very old versions have some other problems when it comes 
to cross-compiling.

> But if we are talking about unified packages for general use, skipping
> of autoreconf seems to be acceptable.
>
> It's possible to define and recommend use of %autotools_update macro,
> which can have arbitrary contents defined by the vendor (e. g. empty).
> If distributors feel the need to call autoreconf, it could be even
> hidden into %configure.

What about passing autoconf cache variables ? I regularly need to do things 
like:

ac_cv_foo=yes \
ac_cv_bar=no \
./configure ...

Needs to be thought of when designing %configure.

> Far the best solution would be encouraging software developers in using
> of latest autotools.

Simply not possible if you're packaging something that's not in active 
maintenance any more. It's up to you (the packager) to deal with it.

> > Only patching both sources and generated files guarantees deterministic
> > behavior of building.
>
> It may easily guarantee indeterministic behavior depending on order of
> chunks in the patch, fraction of second, when the patch was applied,
> file system time accuracy, disc cache size in memory and load of the
> system.
>
> After spending one day of debugging of such issue, I would strongly
> advice to never patch any auto-generated files.

I think it's sometimes necessary (sometimes easier), e.g. I regularly find 
myself patching config.sub to understand "armeb" as machine name. Simple 
two-line patch, far better than trying to run autotools only to find out that 
I have to heavily patch configure.in or other stuff to make my autotools 
generate the files when the original author used another (old) version of 
them.

But sometimes this patching is brutaly smashed to pieces by autotools and 
their nice tendency to sometimes call themselves when running "make". While 
the autotools have made my life as maintainer of cross-compiled packages 
easier I still sometimes want to punch some of the autotools authors for 
things like that.


-- 
Marc Haisenko

Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321