autoconf and epel-5

[Simon Wesp]

Hi all,

i have a little issue with autoconf and epel-5

the statement of the problem:

in configure.ac stands: 
CXXFLAGS="-Wall -O2"

to honor the rpmoptflags i removed this line and create a patch of my
changes.

now i have to run autoconf to implement my changes. no problem in
fedora. in epel-5 it will abort:
http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5...

my idea to handle this problem is:

1) run autoconf in fedora and create a diff of the changes (as patch1)

2) handle it in the specfile:

%if 0%{?fedora}
BuildRequires:   autoconf
%endif

%prep
%setup -q -n %{name}-%{srcversion}

# Patch to remove CXXFLAGS from configure.ac
%patch0 -p1

%if 0%{?rhel}
# Patch for autoconf 2.60
%patch1 -p1
%endif

%build
%if 0%{?fedora}
autoconf
%endif

is this the right way to solve this problem? i didn't found a helpful
text passage in the packaging-guidelines

[Stephen John Smoogen]

On Tue, Feb 24, 2009 at 1:01 PM, Simon Wesp
 wrote:
> Hi all,
>
> i have a little issue with autoconf and epel-5
>
> the statement of the problem:
>
> in configure.ac stands:
> CXXFLAGS="-Wall -O2"
>
> to honor the rpmoptflags i removed this line and create a patch of my
> changes.
>
> now i have to run autoconf to implement my changes. no problem in
> fedora. in epel-5 it will abort:
> http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5...
>
> my idea to handle this problem is:
>
> run autoconf in fedora and create a diff of the changes (as patch1)
>
> handle it in the specfile:
>
> %if 0%{?fedora}
> BuildRequires:   autoconf
> %endif
>
> %prep
> %setup -q -n %{name}-%{srcversion}
>
> # Patch to remove CXXFLAGS from configure.ac
> %patch0 -p1
>
> %if 0%{?rhel}
> # Patch for autoconf 2.60
> %patch1 -p1
> %endif
>
> %build
> %if 0%{?fedora}
> autoconf
> %endif
>
> is this the right way to solve this problem? i didn't found a helpful
> text passage in the packaging-guidelines

That looks close to what the OpenSSH package used to do for dealing
with various autoconf versions. However, not sure what is best
practice either.

[Toshio Kuratomi]

Simon Wesp wrote:
> Hi all,
>
> i have a little issue with autoconf and epel-5
>
> the statement of the problem:
>
> in configure.ac stands: 
> CXXFLAGS="-Wall -O2"
>
> to honor the rpmoptflags i removed this line and create a patch of my
> changes.
>
> now i have to run autoconf to implement my changes. no problem in
> fedora. in epel-5 it will abort:
> http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5...
>
> my idea to handle this problem is:
>
> run autoconf in fedora and create a diff of the changes (as patch1)
>
> handle it in the specfile:
>
> %if 0%{?fedora}
> BuildRequires:   autoconf
> %endif
>
> %prep
> %setup -q -n %{name}-%{srcversion}
>
> # Patch to remove CXXFLAGS from configure.ac
> %patch0 -p1
>
> %if 0%{?rhel}
> # Patch for autoconf 2.60
> %patch1 -p1
> %endif
>
> %build
> %if 0%{?fedora}
> autoconf
> %endif
>
> is this the right way to solve this problem? i didn't found a helpful
> text passage in the packaging-guidelines

That would work.  But if you need a patch for EPEL, you might as well
use the patch in Fedora as well and not run autoconf on either distro.

-Toshio

[Simon Wesp]

Am Tue, 24 Feb 2009 13:45:23 -0800
schrieb Toshio Kuratomi :
> That would work.  But if you need a patch for EPEL, you might as well
> use the patch in Fedora as well and not run autoconf on either distro.

yeah, that would work, but the question is: "is this right or wrong?" i
can use the patch for fedora, too, but it's more beautiful and more
transparent if i use the patch for epel and the _real_ autoconf in
fedora, or?

[Toshio Kuratomi]

Simon Wesp wrote:
> Am Tue, 24 Feb 2009 13:45:23 -0800
> schrieb Toshio Kuratomi :
> > That would work.  But if you need a patch for EPEL, you might as well
> > use the patch in Fedora as well and not run autoconf on either distro.
>
> yeah, that would work, but the question is: "is this right or wrong?" i
> can use the patch for fedora, too, but it's more beautiful and more
> transparent if i use the patch for epel and the _real_ autoconf in
> fedora, or?

It's debatable.  I usually argue that using autoconf is easier for a
reviewer to see what's going on and better for getting the change upstream.

But the other side of the coin is that different versions of autoconf
produce different output and sometimes that output has subtle bugs.

-Toshio

[Adam Williamson]

On Tue, 2009-02-24 at 21:01 +0100, Simon Wesp wrote:
> Hi all,
>
> i have a little issue with autoconf and epel-5
>
> the statement of the problem:
>
> in configure.ac stands: 
> CXXFLAGS="-Wall -O2"
>
> to honor the rpmoptflags i removed this line and create a patch of my
> changes.
>
> now i have to run autoconf to implement my changes. no problem in
> fedora. in epel-5 it will abort:
> http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5...

The most authoritative thing I can find in the Wiki seems to frown on
the practice of patching configure.ac in the first place:

https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

"Autotools-generated source packages are intended to be buildable
without requiring the autotools on the host system. autoconf, automake,
libtoolize and the accompanying autoreconf shouldn't be used in the %
prep or %build sections of a package's spec file. Applying a patch to
update the configure scripts and Makefile.ins is preferred as the
results are predictable and packages are more reproducible."

If this is not in fact the agreed policy, I'd expect the agreed policy
to show up more prominently in a Wiki search for 'autoconf'. :)

Aside from that, I'd say did you read, and try, the advice you were
given in the failure log?

"You have another version of autoconf.  It may work, but is not
guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'."

i.e., see if it works with autoreconf. IMHO it is generally a good idea
to use autoreconf rather than just autoconf anyway, because just using
autoconf is more likely to fail if, say, we go up a major version of
autoconf, and upstream source doesn't have a new release in that time.
autoreconf has at least a better chance of succeeding in that situation
(though it won't always).

[Dan Nicholson]

On Tue, Feb 24, 2009 at 2:06 PM, Adam Williamson  wrote:
> On Tue, 2009-02-24 at 21:01 +0100, Simon Wesp wrote:
> > Hi all,
> >
> > i have a little issue with autoconf and epel-5
> >
> > the statement of the problem:
> >
> > in configure.ac stands:
> > CXXFLAGS="-Wall -O2"
> >
> > to honor the rpmoptflags i removed this line and create a patch of my
> > changes.
> >
> > now i have to run autoconf to implement my changes. no problem in
> > fedora. in epel-5 it will abort:
> > http://buildsys.fedoraproject.org/logs/fedora-5-epel/1476-hosts3d-0.97-3.el5...
>
> The most authoritative thing I can find in the Wiki seems to frown on
> the practice of patching configure.ac in the first place:
>
> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
>
> "Autotools-generated source packages are intended to be buildable
> without requiring the autotools on the host system. autoconf, automake,
> libtoolize and the accompanying autoreconf shouldn't be used in the %
> prep or %build sections of a package's spec file. Applying a patch to
> update the configure scripts and Makefile.ins is preferred as the
> results are predictable and packages are more reproducible."
>
> If this is not in fact the agreed policy, I'd expect the agreed policy
> to show up more prominently in a Wiki search for 'autoconf'. :)
>
> Aside from that, I'd say did you read, and try, the advice you were
> given in the failure log?
>
> "You have another version of autoconf.  It may work, but is not
> guaranteed to.
> If you have problems, you may need to regenerate the build system entirely.
> To do so, use the procedure documented by the package, typically `autoreconf'."
>
> i.e., see if it works with autoreconf. IMHO it is generally a good idea
> to use autoreconf rather than just autoconf anyway, because just using
> autoconf is more likely to fail if, say, we go up a major version of
> autoconf, and upstream source doesn't have a new release in that time.
> autoreconf has at least a better chance of succeeding in that situation
> (though it won't always).

Agreed. Just use "autoreconf -iv". Like Adam says, there's still a
chance it will break, but autoreconf has a lot more smarts about using
the autotools than you or I. The -i|--install is important if the
project uses libtool.

--
Dan

[Jason L Tibbitts III]

> > > > > "AW" == Adam Williamson  writes:

AW> The most authoritative thing I can find in the Wiki seems to frown
AW> on the practice of patching configure.ac in the first place:
AW> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf

Toshio already mentioned that this isn't in any way policy; I just
want to reinforce the point that anyone can write anything anywhere in
the wiki that sounds like packaging policy.  Drafts are discussed by
the packaging committee and may, after ratification by FESCo, be
written into the packaging guidelines.  All of the packaging
guidelines exist in the Packaging namespace on the wiki.  Any other
page in the wiki may be the policy of some other SIG or committee, but
is not an official Fedora packaging guideline.

That isn't to say that such pages aren't useful.  They provide useful
points for discussion.  There's simply no filter on them to ensure
that they are balanced, reasonable or remotely sane.

AW> If this is not in fact the agreed policy, I'd expect the agreed
AW> policy to show up more prominently in a Wiki search for
AW> 'autoconf'. :)

There is no guideline relating to the use of autoconf.  The situation
is analogous to the absence of American federal legislation regulating
the acceptable colors used to paint bike sheds.

- J<

[Adam Williamson]

On Tue, 2009-02-24 at 16:41 -0600, Jason L Tibbitts III wrote:
> > > > > > "AW" == Adam Williamson  writes:
>
> AW> The most authoritative thing I can find in the Wiki seems to frown
> AW> on the practice of patching configure.ac in the first place:
> AW> https://fedoraproject.org/wiki/PackagingDrafts/AutoConf
>
> Toshio already mentioned that this isn't in any way policy; I just
> want to reinforce the point that anyone can write anything anywhere in
> the wiki that sounds like packaging policy.

I understand this, hence the qualified use of 'most authoritative'.
> AW> If this is not in fact the agreed policy, I'd expect the agreed
> AW> policy to show up more prominently in a Wiki search for
> AW> 'autoconf'. :)
>
> There is no guideline relating to the use of autoconf.  The situation
> is analogous to the absence of American federal legislation regulating
> the acceptable colors used to paint bike sheds.

I would say this is an area where consistency of method is important. If
discussion has dragged out with no decision being taken that's a shame,
but I think it's not wasted effort to try and come up with an agreed and
enforced policy for how changes to autotools-managed build scripts
should be handled.

[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...

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