On Thu, Jan 21, 2021 at 11:01:34AM -0500, Zack Weinberg wrote:
> Having said that, switching to *anything else* would be a gigantic
> task -- multiple full-time person-years of effort just for the core --
> and would mean either porting or losing all of the third-party macro
> libraries. I don't think it makes sense to explore this possibility
> any further unless both a lot of funding and a lot of developers
> materialize.
It could be possible for autoconf to become one option of several for
use with automake. Then it would not be necessary to replicate the
entire functionality of autoconf in a new system. People could have
(part of) the configuration written in Perl or other languages.
For this to work, automake would need to change quite a lot, for
example not always using configure.ac as an input file. There would
be the question of information sharing between automake's own checks and
checks done in user configuration code. It would never be trivial
to add a new configuration language, but they could all have similar
characteristics, for example communicating their results as a list
of names and values (i.e. the "name=@name@" of autoconf), some of which
would be required for Automake rules (e.g. whatever configuration method
was used, it would have to yield a value for CC if C files were being
compiled).
Perhaps there could be an Automake variable CONFIGURATION_METHOD
that could select which system was to used ("autoconf" being the
current system). Other options could be to generate the configure
script completely automatically, or to access other programs that
allow some user code in the script.
This all depends on somebody creating a replacement for autoconf, though,
and integrating it with automake.
> A lesser possibility we could think about, would be dusting off GNU M4
> 2.0 and thinking about what we could change about the M4 language to
> make it friendlier for Autoconf's purposes. Again I would want
> funding and developers lined up, but we'd not need quite so much of
> either.
If you ask if the current design of the autotools is something that
should be preserved forever, when you look at what its use is (creating
build systems for software), you would answer that it shouldn't be. M4
is part of this.
> [Bob Friesenhahn]
> > There is a fork of Automake which was re-done to be based on GNU
> > Make. This assumes that makefiles written in GNU make can noticeably
> > improve things. I like your idea of supporting other underlying
> > build tools besides 'make'. Make's dependence on matching rules and
> > file time stamps is problematic and it does not scale.
>
> I haven't ever followed automake development closely. I know that
> at least one person has tried to write a set of GNU Make library files
> intended to replace it altogether, but I've never seen anyone *finish*
> that project. I'd very much like to see someone give that another go.
>
> The alternative to the Make family of tools, that I'm most familiar
> with, is Ninja, and it also depends on matching rules and file time
> stamps. What do you have in mind as a replacement for these things?
> Is there already an alternative tool that you like?
One issue here is that Makefile.am can contain Makefile rules, which
transfer cleanly to use by "make", but possibly not for other programs
like ninja. (I don't know anything about ninja, though.)
> I have a lot more sympathy with people who are annoyed with the GNU
> *project* and/or the FSF. I have any number of my own grievances with
> them. However, I would prefer not to get into that in this
> conversation, because it's liable to drag it off-topic and/or turn
> into a flame war. Let's declare the known obstacles imposed on
> Autotools by the FSF -- concretely, the requirement for copyright
> assignment paperwork and the requirement not to use proprietary CI and
> forge services -- immobile and out-of-scope for this discussion.
There could be a discussion to be had about project governance and how
to stimulate development in GNU packages: advertising for contributors,
promoting use of the package, encouraging exploratory development. I
don't have any concrete suggestions, though, and many changes are also
possible for the worse.
