Alire: Why does a crate's build config not get committed?

General
1

As an experiment, I just added gnat2022to a crate’s GPR configuration, which used to be the Alire default. I noticed that Git didn’t pick up this change, and discovered that Alire had included the config/ directory in .gitignore. This surprised me because I consider the build configuration to be an important part of the project files. For example, how would others know to use the 2022 standard for builds?

I couldn’t find documentation on this topic. Can somebody here shed some light on it?

2

The config is generated atleast whenever alr build is run. I think you can select 2022 with the following in alire.toml but I’ll check in my latest .toml when I get to work.

[build-switches]
"*".ada_version = ["-gnat2022"]

You might want to run alr update after to update config

p.s. There is actually a bit of a bug that is being considered that Gnat Studio sees a broken project for some crates until alr build is run.

3

As an addition to @kevlar700, indeed alr recreate /config at build time if it does not exist or is not up to date. It is added to the .gitignore because it is “platform-specific”:

   Alire_Host_OS := "linux";
   Alire_Host_Arch := "x86_64";
4

I didn’t know about that, I’ve been changing the gpr (not the config one).

5

I was doing both because I guess I didn’t realise you had to run alr update or alr build. Actually that doesn’t make sense because I would be building to test it in Gnat Studio. Maybe it was broken for a time but I think it works now :thinking:

6

Yeah I have dropped the & -gnat2022 in my latest project gpr files.

7

Now it makes sense. The build settings in a new project.gpr are explicit reflections of the implicit Alire settings, and you always control them from project.toml. Thank you!