How do you make an Ada package available both for people who use Alire and people who do not?

Help
1

I’ve written an Ada package that I may eventually want to publish, and as a first step I’ve started making an Alire crate of it. However, Alire really really wants you to use its config project file in the config subdirectory, which it regenerates from the alire.toml, which makes it hard for people who don’t want to use Alire to use the library.

Does anyone have any good approaches to handling this?

I could keep a repo with the my original non-alire gpr files, and have a makefile target that basically checks for differences and exports the changed files into another repo with alire-specific stuff, but that’s a pain.

I suspect that if I just used a simpler gpr file that ignored the alire stuff it would break alire in non-obvious ways.

I suppose I could just keep everything in one repo and set things up so the alire gpr file includes the simpler non-alire gpr file, but then those two have to have different filenames, and there is the confusing situtation where there are two gpr files.

1 Like
2

I do something that may be over the top to accomplish it, but I wanted it so that if someone didn’t want to use alire, they could delete the alire.toml and the alire subfolder and just use the gpr file as is. I also want commands like alr build --release to still work in the setup I accomplished that by pointing alire to an aggregate project file. See my example here:

Basically, I create the alire subfolder myself, and place an alire_default.gpr file in there that is an aggregate project that calls my actual project file. So take a look at alire.toml, alire/alire_default.gpr and bullfrog.gpr for the setup.

It may be overkill, but I don’t know how all the things work honestly.

2 Likes
3

Well, that looks interesting. I can’t try it out right now, but I’ll definitely give it a try soon. Thanks!

4

There’s no requirement to use the config files that are generated by Alire; they’re just there as a convenience. You’re free to modify your GPR file to remove the dependency on the generated config file and set your own compiler switches etc. You can also tell Alire not to generate GPR/Ada/C config files by adding these to your alire.toml:

[configuration]
generate_ada = false
generate_gpr = false
generate_c = false
2 Likes
5

One option is to just include the config directory under configuration control. In order to avoid having modified files whenever you change any Alire option, you can do that only at a final step in which you create a release branch, run alr build --release and add the files only on that branch. Then you direct non-alire users to build from the latest release branch, requiring them to provide all the dependencies and configure GPR_PROJECT_PATH accordingly. The same can be done if you provide a downloadable ZIP containing sources.

Git should have a way to command it to include files under configuration control but ignoring any modification you might do to them, but, as far as I know, that option does not exist.

6

Maybe this helps:

git update-index --assume-unchanged <file>
7

I think that is only for your personal local changes? I was thinking it may not push that setting to the remote side, meaning other contributors could potentially push changes unless they too use that setting? Or am I mistaken.

8

You’re right, it’s just local. I didn’t catch that central aspect reading your post.

9

Alire is tolerant with several .gpr project files and uses the one you mention in the .toml description.
So my solution is to have an Alire-friendly .gpr, and a more standalone .gpr for people who don’t want to use Alire for various reasons.
In a couple of my crates, it goes further with a copy of sources of a dependent crate; those sources are only visible to the standalone .gpr, whereas the Alire-friendly .gpr will “with” the depedent project (and same for the corresponding crates).
For instance, the APDF crate depends on the GID crate for image insertions. Alire uses pdf_out_project_tree.gpr, which will “with” gid.gpr and everybody is happy in Alire’s wonderland.
Those who grab the APDF project directly from GitHub or SourceForge can play with it immediately by using pdf_out.gpr.
The only cumbersome side for the maintainer is to synchronize the contents pdf_out_project_tree.gpr and pdf_out.gpr on changes.
A solution would be a pdf_out_common.gpr that both pdf_out_project_tree.gpr and pdf_out.gpr extend - but it would bring more complexity, something you perhaps don’t want to throw at people who do not use Alire.

2 Likes
10

I faced this issue recently.
As @zertovitch said, It turns into painful synchronizations and naming I think.
Thus I give a try to configurable GPR, for instance:

   type Alire_Type is ("True", "False");
   Alire : Alire_Type := External ("ALIRE", "False");
   case Alire is
      when "True" =>
         for Object_Dir  use "obj";
         for Exec_Dir    use "bin";
      when "False" =>
         for Object_Dir  use "../obj";
         for Exec_Dir    use "../../bin";
   end case;
2 Likes