<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2013-06-20 14:19, Jonathan Masters
wrote:<br>
</div>
<blockquote
cite="mid:1630165827.22401922.1371730792621.JavaMail.root@zmail15.collab.prod.int.phx2.redhat.com"
type="cite">
<pre wrap="">Indeed. This was a concern I raised when we first began the bootstrap. Blindly rerunning autoreconf in every case is a really bad idea. But doing it in a discretionary way, allowing the package maintainer to influence what happens (they in theory know whether this will work for their package and their upstream) is good.
Sent from my Android phone using TouchDown (<a class="moz-txt-link-abbreviated" href="http://www.nitrodesk.com">www.nitrodesk.com</a>)
-----Original Message-----
From: Ben Boeckel [<a class="moz-txt-link-abbreviated" href="mailto:mathstuf@gmail.com">mathstuf@gmail.com</a>]
Received: Thursday, 20 Jun 2013, 7:53
To: <a class="moz-txt-link-abbreviated" href="mailto:devel@lists.fedoraproject.org">devel@lists.fedoraproject.org</a>
Subject: Re: rpm and config.{guess, sub} (was [aarch64 bugs] dpkg: Does not support aarch64 in f19 and rawhide bug #925276)
On Mon, 17 Jun, 2013 at 15:29:39 GMT, Michael Schwendt wrote:
</pre>
<blockquote type="cite">
<pre wrap="">One problem with that is, one cannot "blindly" run autoreconf -fi and
expect it to be 100% compatible with the multitude of Autotools' based
projects. Typically one will need to update the configure script, m4
macros as well as Makefile.{am,in} templates. And if one doesn't verify
the build framework, one can miss files where regenerating them drops
stuff (as one example, config.h.in files where someone has inserted
stuff the wrong way).
</pre>
</blockquote>
<pre wrap="">
There are also those rare upstreams which run autoreconf once, commit
the generated files, then make "minor" changes to configure and friends
directly. Running autoreconf on these projects is bound to fail and
upstream might be unhappy moving "back" to editing the .in and .ac files
directly.
--Ben
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
Hm... it actually seems that there is a lot of common ground here,
and quite different from what a newbie will find if googling [1].
Yes, it's an old draft, but in a sense it't the most official
document found, I guess.<br>
<br>
We have at least three cases?<br>
- Ben's case: projects running auto(re)conf once, then committing
and maintaining the generated files (and some years later, in
desperation, goes for cmake...)<br>
- Projects which intitially had a working autotools setup which have
become more or less unusable in a modern environment.<br>
- Projects which have a well maintained, working autotools setup -
here it's natural to run autoreconf as part of the build.<br>
<br>
Seems that we all agree that the last situation is the preferred
one. In the other scenarios, it might make make sense to try to help
upstream to update the obsolete configure.in/ac and Makefile.am. Or
it just might not, and it's better to use the generated fiels.<br>
<br>
This should really be a fpc ticket before we lose everything.
However, my fpc quota has expired... ;)<br>
<br>
--alec <br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://fedoraproject.org/wiki/PackagingDrafts/AutoConf">https://fedoraproject.org/wiki/PackagingDrafts/AutoConf</a><br>
</body>
</html>