autoconf and epel-5

[Stepan Kasal]

Hello,

[obviously, I wasn't able to _read_ the thread, but a quick grep
seems to indicate my point has not been mentioned yet, at least the
first solution I'm going to recommend]

on Tue, Feb 24, 2009 at 09:01:10PM +0100, Simon Wesp wrote:
> in configure.ac stands: 
> CXXFLAGS="-Wall -O2"

As you surely know, this is a bug, please report it to hosts3d
developers.

CXXFLAGS can be overrided at any time, so you can let configure to
hose the default and then override at make time:
	make CXXFLAGS='%{rpmoptflags}'
and, to be sure, again in %install
	make CXXFLAGS='%{rpmoptflags}' install

In theory, the checks performed by configure might be affected by the
incorrect value of CXXFLAGS, but I do not think this is a problem in
practice.

That presents the easiest way to fix the issue.

[Yes, stop reading here, unless you are really curious.]

[Congratulations and kind regards to the wise ones who leave us at
the moment.  Stepan]

> fedora. in epel-5 it will abort:
> http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5/i386/build.log

The error message says that the version of autoconf that has been
used when aclocal.m4 was created is not compatible with the version
you are currently using.  Actually, this is only one of the complex
interconnections between Autoconf and Automake.  You always have to
call aclocal, autoconf, and automake in the spec file.

A simple way to refresh both of these is:

BuildRequire: autoconf automake
..
%build
autoreconf -f -i

That presents the second easiest solution.

[Last chance to leave; good bye to the wise ones.  Stepan]

A side note:
it is often mentioned that running autotools in spec file can trigger
subtle bugs.  That is true, but most of these bugs are caused by
problematic code in configure.ac (or Makefile.am's), so the fix is to
clean up these and submit the resulting patches upstream, which is
generally a good thing.

Back to our problem.

Then come the solutions which patch generated files:

3) Third solution, with a bit of hacking:

Since the change to configure.ac is minimal and you know the expected
effect on configure, you can do the thing manually.
In both cases, fix the date of configure.ac.  Make would try
to run aclocal, autoconf, and automake otherwise, resulting in subtle
differences between builds depending on presence of autoconf and
automake in the tree.

You can either create a patch that deletes the line from configure:

%prep
..
# patches both configure.ac and configure
%patch77 -p1 -b.cxxflags
touch -r configure.ac.cxxflags configure.ac

or use sed

%prep
..
touch -r configure.ac configure.mystamp
sed -i /^CXXFLAGS=/d configure.ac configure
touch -r configure.mystamp configure.ac
rm configure.mystamp

4) Fourth solution would be to create a patch that contains all the
results of autoreconf run.

Though it might seem that the Fedora Packaging Guidelines encourage
this type of solution, it the most tricky one.

You have to take care of all the following things:

- you have to have automake installed on the machine and include also
  the patches to aclocal.m4 and all the Makefile.in's
- OTOH, you should omit the contents of autom4te.cache subdirectory
  from the new tree
- you have to get the timestamps right, e.g. by reorganizing the diffs
  for individial files in the patch; configure.ac has to be the
  oldest, then aclocal.m4, then all others (configure and
  Makefile.in's)

Happy hacking,
	Stepan