Provide profile (build mode) options to other alire commands besides build

[dalybrown]

Currently alr build allows one to specify the profile to build (release, validation, and development).

It would be nice to specify those profiles for other alire commands where we may want to, for example, use the release profile when running unit tests with gnatcov or when proving code with gnatprove.

Currently, when we run these commands, alire uses alr exec ... but there is no way (as far as I know) to specify the profile. I believe it defaults to the development profile if not profile exists, or will use the previous profile that the project was built with. However, in a CI/CD environment, there quite possibly isn't any profile information available so it will default to development.

[Fabien-Chouteau]

Currently, when we run these commands, alire uses alr exec ... but there is no way (as far as I know) to specify the profile.

These commands will take the last profile used for alr build or the default development mode for the root crate.

I don't think it's reasonable to have all those switches in all alr commands. Right now the workflow is to first set the profile with a build command, and then run the other commands.

Note that the build profile should not have any impact on the gnatprove run.

[dalybrown]

Maybe it's an OCD thing but I prefer to use the same switches for building/testing/proving my code. However, when run in a CI/CD pipeline, those jobs are separate so there is no last profile used. I suppose I could save all the build artifacts from the build job for subsequent jobs but that's a bit of a waste of storage.

[mosteo]

Could you use a bit of scripting to append to the alire.toml file and set the build profiles in there?

[dalybrown]

I can definitely work around it I guess - I just thought it would be a desirable feature to control the switches used when unit testing / running coverage. (I understand they don't mean much for proving the code.)

[dalybrown]

What if you want to provide certain flags for running unit tests (e.g., gnattest) that don't have any previous knowledge of a build? I still think it makes sense to be able to provide the profile when running commands other than build.

[dalybrown]

Alternatively, if you don't want to add the option to specify profiles for other commands (a use case we require) would having a configuration option where you can set the default profile be something you would entertain? Currently it defaults to development but if we could change that default it would solve my use case.

[mosteo]

I may be missing something, but I think that setting the profile you need in alire.toml should be the simplest approach.

[dalybrown]

Maybe I missed that! Can you set the default profile in alire.toml? I guess I missed that in the docs:

[build-profiles]
depend1 = "validation" # Set depend1 build profile to validation
depend2 = "development" # Set depend2 build profile to development
my_crate = "release" # Set my_crate build profile to release

Presumably you can still override this setting on the command line? (I guess I can try that out).

Sorry I missed that - you can delete this issue. I can work with that. Cheers.

[mosteo]

Yes, by default alr build uses the settings in the manifest. Only when explicitly passing other settings with alr build switches you override the manifest for that build. So the idea is that you give the intended defaults in the manifest, and use the explicit options of build for convenience in selected builds.

Note that --profiles can override or respect manifest profiles, see alr help build.

You can check the last build profiles to make sure with alr config last_build_profile