Hi Karl,
I think you are right. Let us concentrate on Automake first. Your
changes to the application are making the statements more clear, thank
you. I removed OpenJDK and LibreOffice, as they are not using Automake.
If you know two other widely known projects using Automake, we could add
them instead.
Find the complete application text below. Can you please confirm that I
should submit the application to STF?
Kind regards,
Christoph
>> Application
> Category
Join the Bug Resillience Program
> Application name
Autotools
>> Project
> Project title
Automake Direct Contribution 2024
> 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, 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?
[x] Direct Contributions
[ ] Bug Bounty Program
[ ] Secure Code Audits
> 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.
We are hoping for direct contributions, particularly fixes for open bugs.
https://debbugs.gnu.org/cgi/pkgreport.cgi?package=automake
