Hi Christoph and all - back on the Sovereign Tech Fund
application. Here's my first cut at tweaking the wording.
Thanks for doing all this. -k
Draft of applications (questions are with > at the left of the line):
> I acknowledge:
>
> All code and documentation to be supported must be licensed such
> that it may be freely reusable, changeable and redistributable
As mentioned, we will need Neighborhoodie to sign a copyright
assignment/disclaimer to the FSF.
> Project title
Autoconf & Automake Direct Contribution 2024
I think autoconf and automake should be submitted separately? Even
though there is clearly a lot of overlap, and technically automake is
entirely dependent on autoconf, the two projects are implemented quite
differently, have separate bug lists, separate maintainers, etc. It is
possible to work on Automake without ever delving deeply into Autoconf
(and of course the reverse is even more true :).
I'm going to adjust the rest to emphasize Automake.
> Link to project website
https://www.gnu.org/software/automake/
> Link to project repository
https://git.savannah.gnu.org/cgit/automake.git
> Where is your open source technology project being used (describe
> all user bases)?
GNU Autoconf and GNU Automake are the core of the GNU Autotools. They
help in making source code packages portable to virtually all Unix-like
systems. They are used by GNU GCC, LibreOffice, and OpenJDK, among
thousands of other packages. The interface that they implement is the
standard for GNU.
> Why do you consider your open source technology project to be
> relevant and critical?
Many projects rely on Automake (and Autoconf) as crucial part of their
build system. Moving to alternatives is challenging. Without a working
build system, users might not be able to build the software using the
build system.
> How does your open source technology benefit the public interest?
A build system is like water or electricity, it is supposed to work and
nobody thinks about it. Once service is disrupted, we realize how much
depends on it. Many users never know of Automake. The programmers and
packagers work behind the scenes, relying on the build systems
effectiveness.
> Please describe the history and state of development of your open
> source technology
Automake automatically generates input files for Autoconf and adds
dependency tracking. Version 1.0 was released in 1996. Automake is
(primarily) implemented in Perl, and also uses m4 and shell scripts.
Automake is completely dependent on Autoconf, which is an extensible
package of M4 macros that produce shell scripts to automatically
configure software source code packages.
Autoconf and to a somewhat lesser extent Automake became very popular in
the 2000s, as extremely portable and adaptable build systems. It is
often possible to configure a package for compilation on a new system
without user intervention.
Plenty of projects haved switched to other build systems for various
reasons, but numerous projects still rely on the Autotools.
> Which BRP services are you interested in?
Direct contributions, particularly fixes for open bugs.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake
>Describe why your project needs those services?
Automake (and Autoconf) have relatively few contributors, and thus
releases are infrequent and some bugs, especially system-dependent ones,
have remained unfixed for years. The many dependencies (GNU m4, GNU
libtool, plus (f)lex, bison/yacc, compilers, etc.) make it relatively
difficult for newcomers to make substantive contributions without
significant effort.
On the other hand, C, C++, Python, and other languages are evolving, and
the new versions of these language standards are often
backward-incompatible with existing code and practice. Thus the
Autotools must adjust.
