Skip to content

test/config: tracked Alire-regenerated files drift per host on every build #15

Description

@abitofhelp

Summary

The following three tracked files are regenerated by Alire on every test-crate build and drift per host, repeatedly dirtying the working tree and interrupting release cleanup operations:

  • `test/config/clara_tests_config.ads`
  • `test/config/clara_tests_config.gpr`
  • `test/config/clara_tests_config.h`

Evidence

Observed during the clara PR #14 (v1.0.0 → v1.0.1) cleanup gate on 2026-06-09. After running the in-container PR #14 build validation (`alr build -- -XGNATCOLL_ICONV_OPT=` in `dev-container-ada-system-1`), the working tree showed:

```
modified: test/config/clara_tests_config.ads
modified: test/config/clara_tests_config.gpr
modified: test/config/clara_tests_config.h
```

The diff content showed two distinct kinds of drift:

1. Host triple flip (Alire's regeneration writes the build host's identity):

```diff

  • Alire_Host_OS := "macos";
  • Alire_Host_OS := "linux";
  • Alire_Host_Arch := "x86_64";
  • Alire_Host_Arch := "aarch64";
  • Alire_Host_Distro := "homebrew";
  • Alire_Host_Distro := "ubuntu";
    ```

The macOS host carries the macos/x86_64/homebrew triple; the dev container's aarch64 Ubuntu carries linux/aarch64/ubuntu. Every cross-host build flips these. Note: the `Alire_Host_Arch` value tracked on `main` (`x86_64`) does not match this MacBook (arm64) either, suggesting the baseline was committed from a different host than the current dev environment.

2. Tracked-baseline content drift: the tracked `clara_tests_config.h` on `main` still carries leftover `functional_tests` content (the template clara was cloned from) and the stale `CRATE_VERSION "3.0.0"`:

```diff
-/* Configuration for functional_tests generated by Alire /
-#ifndef FUNCTIONAL_TESTS_CONFIG_H
-#define FUNCTIONAL_TESTS_CONFIG_H
-#define CRATE_VERSION "3.0.0"
-#define CRATE_NAME "functional_tests"
+/
Configuration for clara_tests generated by Alire */
+#ifndef CLARA_TESTS_CONFIG_H
+#define CLARA_TESTS_CONFIG_H
+#define CRATE_VERSION "1.0.1"
+#define CRATE_NAME "clara_tests"
```

The `.ads` and `.gpr` files carry the same stale `Crate_Version := "3.0.0"` on `main`. So the regenerated files are arguably more correct than the tracked baseline (they fix the `functional_tests` leftover and bump `Crate_Version` to match `test/alire.toml` version 1.0.1) but also carry the host-triple flip.

Why this matters

  • Release-cleanup discipline is interrupted: PR chore(release): bump version 1.0.0 -> 1.0.1 (first Alire-published release) #14 (v1.0.1 version bump) cleanup required `git restore` of these files before `git switch main` could be performed cleanly. This is a recurring tax on every release operation that crosses build hosts.
  • The tracked baseline is wrong: at minimum, the `functional_tests` leftover content in `.h` and the stale `CRATE_VERSION "3.0.0"` (vs the actual `test/alire.toml` version `1.0.1`) should not be on `main`.

Out of scope

Possible directions (for the investigator, not a decision here)

  1. Add `test/config/clara_tests_config.{ads,gpr,h}` to `.gitignore` and remove them from tracking, since Alire regenerates them on every build. Most similar Alire crates do not track these files. (`functional` may or may not — worth comparing.)
  2. Keep them tracked but normalize the host triple to a stable value (e.g., regenerate from a canonical CI host and re-baseline) so the on-`main` content is what every build host writes — at the cost of needing a re-baseline whenever Alire's generation logic changes.
  3. Investigate why the tracked `.h` carries `functional_tests` content — likely a copy-paste from the functional template at clara's inception, never corrected.

Reference

Refs: adafmt#42

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions