<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 5/4/23 12:59, Joshua C. Colp wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAM0A2Z2A3aqbug6+Y214y-sEaCAP_CmxHUC_z=ob=25F=K0nrw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div class="gmail_quote">
<div>I'm not sure what build-environment specific parameters
you are referring to, unless you mean the version of
autoconf on the system. The issue Sean saw was that if
developers generated the configure using different autoconf
versions, the output would be different and could result in
large reviews. From an actual non-developer people who use
Asterisk perspective, to the best of my knowledge we've
never seen any issues with either the checked in configure.
The logic certainly, but that's not the result of the
process of producing the configure script but the backing
autoconf logic that was written by someone.</div>
</div>
</div>
</blockquote>
<p>Every build environment is different so configure will be
different too. The fact that these differences are appearing in
reviews pretty much proves it.</p>
<p>There is also the possibility of configure being stale which is
avoided entirely when it does not exist.<br>
</p>
<blockquote type="cite"
cite="mid:CAM0A2Z2A3aqbug6+Y214y-sEaCAP_CmxHUC_z=ob=25F=K0nrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>As for Makefiles, the Asterisk ones are not generated.
They're written manually. Are you also proposing changing
the build system so those are now generated?<br>
<br>
That's a fundamentally breaking change if tags and releases
do not contain a configure already. The benefit would need
to be large enough to justify it. What additional benefits
are there?</div>
</div>
</div>
</blockquote>
Apologies, I failed to notice Asterisk lacking Makefile.am. If
configure is to be generated from configure.ac, it would make sense
to generate Makefile from Makefile.am too. It is not a hard
requirement.<br>
<p>I didn't say to remove configure from releases (tarballs), I
merely suggested to have identical build instructions. Users can
run the provide configure if they want or generate their own copy,
whichever they prefer.</p>
<p>Instructions can state to generate configure if/when not present.
Honestly it doesn't really matter whether configure is
re-generated as it should work regardless. It just means the same
instructions can be used for all builds, simplifying documentation
and requiring less to remember.<br>
</p>
<p>
<blockquote type="cite">Some users do get tags from git, instead
of downloading the tarball. I don't think changing that is
really worth it. Adding generation of configure to the release
process is minor.</blockquote>
<br>
The only time I download a tarball for anything is when no
alternative exists. It is less work to pull the latest changes
than downloading a fresh tarball, extracting, etc. And even when
using a tarball I will re-generate configure, Makefile, etc just
to be sure the build won't fail for some vague reason that
requires hours of debugging.</p>
<pre class="moz-signature" cols="72">--
Dennis Buteyn
Xorcom Ltd</pre>
</body>
</html>