autoconf-archive

Overview

Autoconf Archive is a collection of reusable Autoconf macros for projects that generate portable configure scripts with Autoconf. It exists so upstream projects can reuse common checks and helper macros instead of copying local ad hoc snippets into every package. The archive is maintained as a separate upstream project and is commonly packaged in Linux distributions because many build systems depend on these macros during source configuration. (gnu.org)

For package maintainers, this repository is useful when a project uses AX_... macros from the archive in configure.ac or related files. For users, the package matters mostly as a build-time helper; it is not usually a runtime component of applications. NiceOS maintainers should verify the exact dependency pattern for each consumer before assuming that packaging this archive is sufficient for all build environments. (gnu.org)

Purpose and typical use cases

Typical uses include:

• providing AX_... macros to Autoconf-based projects;
• enabling configure-time checks for compiler, library, header, or tool availability;
• reducing duplication across upstream build systems;
• making distro rebuilds of Autotools-based software more consistent.

Typical users include:

• distribution packagers and RPM maintainers;
• upstream developers who maintain configure.ac or Makefile.am files;
• build and CI/CD maintainers who need reproducible source configuration;
• release engineers working on Autotools-based projects.

Upstream project

The upstream project is the GNU Autoconf Archive. Its official site describes it as a collection of freely reusable Autoconf macros, and its documentation lists many macros under the AX_ namespace. The archive is also documented as being maintained in a public Git repository. (gnu.org)

Autoconf itself documents that public macros are used during the generation of portable configure scripts, which is the broader context in which this archive is consumed. (gnu.org)

Dist-git repository contents

This NiceOS dist-git repository is organized as follows:

• SPECS/ — RPM spec files and packaging metadata;
• SOURCES/ — source integrity manifests and related source metadata;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present.

The repository intentionally does not store large upstream source archives in Git. Instead, the source location and integrity information are tracked through files in SOURCES/. This keeps the repository small and avoids churn when upstream source tarballs change. The manifest files are what maintainers should inspect when validating where sources come from and whether the recorded source set still matches the package they intend to ship. (gnu.org)

Source storage and integrity policy

NiceOS keeps the upstream source archive out of the Git history on purpose. Source integrity is represented by manifest files in SOURCES/, not by embedding archive contents in the repository.

Before updating the package, maintainers should verify that:

• the manifest still points to the intended upstream source set;
• any renamed, added, or removed source entries are reflected in SOURCES/;
• the spec file still matches the packaging model expected by the archive;
• no local patch assumes an older macro layout or file naming pattern.

Do not rely on generated or version-specific values in this repository for long-term documentation. Those details should be checked in the packaging files at update time.

NiceOS maintenance notes

When updating this package, NiceOS maintainers should check the following:

• whether upstream has changed macro names, documentation layout, or installation paths;
• whether any downstream patches are still needed;
• whether the RPM spec needs regeneration because the installed file list changed;
• whether the SOURCES/ manifest must be refreshed after a source update;
• whether SBOM/ material, if used, needs to be regenerated from the new package inputs;
• whether dependent packages in NiceOS still build against the updated archive.

Risks to consider:

• consumer builds may fail if they rely on a macro that moved, was renamed, or was removed upstream;
• an update may expose assumptions in downstream configure scripts that were not covered by previous builds;
• changes in installed macro paths can affect %files handling and package verification steps.

Build and verification checklist

Before submitting or merging an update, RPM maintainers should usually verify:

• the spec parses cleanly with the intended build macros;
• the source manifest in SOURCES/ matches the intended upstream inputs;
• the package builds in a clean mock or comparable isolated build environment;
• installed macro files land in the expected locations;
• the package metadata and SBOM files, if present, still describe the shipped content correctly;
• dependent packages can still run their Autoconf-based configure checks successfully;
• any downstream patch set is still minimal and necessary.

A practical test plan is to rebuild at least one reverse dependency that uses Autoconf Archive macros and confirm that its configure phase still passes.

References

• GNU Autoconf Archive
• GNU Autoconf Archive: Introduction
• GNU Autoconf Archive: The Macros
• GNU Autoconf Archive: How to contribute
• GNU Autoconf Archive: Downloads
• GNU Autoconf manual

Russian documentation

• README_RU.md

Dist-git repository notes

• Package repository: rpms/autoconf-archive
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.