Calling autoconf in a spec.

[Kevin Kofler]

Sam Varshavchik wrote:

> Kevin Kofler writes:
> 
>> Sam Varshavchik wrote:
>> > Ok, then when you patch configure.in, configure.ac, and/or Makefile.am,
>> > be sure to also specify:
>> >
>> > BuildRequires: autoconf=[version]
>> >
>> > and
>> >
>> > BuildRequires: automake=[version]
>> >
>> > in order to have a reproducible build.
>>
>> Nonsense. Even many upstreams do that.
> 
> Can you translate that. It's nonsense because many upstreams do that?

Oops, I forgot the most important word. :-(

Nonsense. Even many upstreams DON'T do that.

Only very few upstreams use a specific version of autoconf and/or automake, 
most upstreams will just use whatever version happens to be on the 
developer's system that day.

>>                                         (I know I don't. On the autocrap-
>> using projects I inherited, I just run "autoreconf -i -f" with whatever
>> version I have on my system and ignore all the warnings.)
> 
> Sure. You must be able to tell, at a glance, which version of autoconf and
> automake were used by upstream, and what the impact will be as a result of
> rebuilding with, most likely, Fedora's different version, even before
> introducing any patches.

Even upstream itself will generally just run "autoreconf -i -f" without even 
looking at the warnings. The warnings are generally such incomprehensible 
gibberish that nobody who isn't an autotools developer even understands them 
at all.

> I mean, after all, autoconf has such a perfect record of 100% backwards
> compatibility, as far as I can remember.

That's exactly why the autotools suck, and upstream projects should be using 
a build system which actually cares about backwards compatibility.

But in practice, the right thing to do is to just run "autoreconf -i -f" in 
%prep, and fix any issues if they fail the build or get reported by users, 
exactly the same way as we handle incompatible GCC changes.

        Kevin Kofler