MESSAGE
DATE | 2021-01-21 |
FROM | Gavin Smith
|
SUBJECT | Re: [Hangout - NYLXS] Future plans for Autotools
|
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=-at-name-at-" 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.
_______________________________________________ Hangout mailing list Hangout-at-nylxs.com http://lists.mrbrklyn.com/mailman/listinfo/hangout
|
|