[asterisk-dev] Removing configure from tree
Jaco Kroon
jaco at uls.co.za
Thu May 4 05:08:50 CDT 2023
Hi Joshua,
My 5c below.
On 2023/05/04 11:59, Joshua C. Colp wrote:
> On Thu, May 4, 2023 at 6:45 AM Dennis Buteyn
> <dennis.buteyn at xorcom.com> wrote:
>
> On 5/3/23 22:48, Joshua C. Colp wrote:
>> Greetings all,
>>
>> Sean Bright brought up on IRC the removal of configure from git.
>> This may be impactful since some users (not necessarily
>> developers) may not understand the build system when building
>> from branches (not tags or releases) and become confused when
>> configure is not present which is why I disagreed with doing so
>> on IRC. I'm curious though what others think of such a change. I
>> think to be acceptable it would need:
>>
>> 1. To regenerate configure if configure.ac <http://configure.ac>
>> has been changed, so that developers don't have a stale configure
>> 2. To provide instructions if configure is not present and "make"
>> is run, I'm on the fence on automatically running it
>> 3. Releases (and tags) would need to have a generated configure
>> in them
>>
>> Thoughts?
> Sean is correct that configure should not be present in the source
> tree because it contains build-environment specific parameters.
> For the same reason, Makefile should also not be present in the
> source tree.
>
>
> 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.
Spot on. The generated configure should be posix-shell compliant and
thus not care which shell is being used, and basically from that
determine everything else (ie, is openssl available or not, do we use
pjsip etc ...).
>
> 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?
Please no.
>
> Running make without configure being present would mean Makefile
> is also not present. As make is (fortunately) not sentient and
> does not know that Makefile is to be generated, it would
> reasonably state that no Makefile has been found. I'm not sure how
> one would convey additional instructions to users in such a case.
>
> Many Automake/Autotools projects provide some bootstrap script to
> generate configure from configure.ac <http://configure.ac>, with
> step-by-step instructions on how to build (bootstrap, configure,
> make).
>
> To make building as simple as possible, instructions for building
> from a branch, tag or any other source should be identical.
>
> 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?
The norm for many/most projects seem to be:
1. No generated files in git, ever, even for tags/release branches. In
this case configure.ac yes, configure no.
2. Generated files in archives, ie, in the downloadable
asterisk-x.y.z.tar.gz file there should be a ./configure.
For me this makes sense since MOST users will simply download the tgz
and move on with their lives, thus no change to their workflow.
For developers (checking out from git), surely running an extra
./bootstrap.sh prior to ./configure isn't too much to ask?
Thus there is a change required to the release process for generating
the archive (which is where github seems to have a pitfall in that
automated download archives won't work as expected unless there is an
option to first run a script on the checked out tree) to first run
./bootstrap.sh prior to creating the archive.
Kind Regards,
Jaco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20230504/08c0a37c/attachment.html>
More information about the asterisk-dev
mailing list