Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file

Jakub Narebski <jnareb@gmail.com> writes:

I had an impression that your spec.in change made it required.

It is still somewhat dubious to me if we can keep this "opt-in". I noticed that it at least lacks a few extra commands to "clean" target of the main Makefile, and adding them by itself is not so bad, but who knows what else it would bring in when the series finishes. I would not be surprised if we start touching *.c and *.h files with new autoconf-compatible "#ifdef HAVE_XXX" and at that point I will say "I told you so".

I am not opposed to giving an alternative, semi-automated way to edit config.mak to the users, and if that is our goal, we should ship the configure script in the source tarball at least, and probably we should have the configure script in the revisions as well. Using autoconf is not the goal here -- giving ./configure as an alternative way to manage config.mak is.

But if we have autoconf scripts _and_ configure script in revisions, we are talking about version controlling generated stuff, and I'd like to avoid that at all cost.

Maybe an alternative is to just add configure script in the source tree _without_ adding any of the autoconf scripts to the git repository. The users can choose to use that script to manage config.mak but do not have to. And I do not mind getting occasional updates to the configure script in the source tree, and I do not care if you build it by hand or use autoconf to generate it, as long as the configure script is readable, debuggable and maintainable.

The source to generate that configure script might be autoconf scripts and you would want to version control that. That is fine but I think that would be a separate project of yours, and you may call that the git-build-config project. And I do not mind hosting that somewhere under contrib/ area in the git repository in order to give it wider exposure.

That would end up in the same situation as having the source and generated files under the version control, but I think at the philosophical level the two are vastly different, in that the things under contrib/ are not part of git.git but are there only for convenience. I will not be the one who is responsible to run autoconf in there every time we make changes to the system and propagate the changes to the main configure script. The configure script generated by the end user in contrib/autoconf may not match the toplevel configure script (the end user may have different version of autoconf, for example) but that is not a bug, as long as the toplevel configure script, which might be output by an older version of autoconf, works correctly.

The above assumes that the configure script generated by your autoconf script is readable and maintainable at all. Otherwise it would not make any sense to have configure under version control.