I’m trying to set up a new project that consists of a library and an application that uses that library. I’m not sure how to best configure this so that things work smoothly with Alire, and so I can edit the sources of both the library and the application “simultaneously” (they are being developed together).
My attempts to include the application code in the same Alire crate as the library produces errors saying that “main cannot be a source in a library project.” That makes sense to me, leading me to think that two GPR files are required. But will Alire understand what’s going on?
Another approach I considered is using two separate Alire crates: one for the library and one for the application. That appeals to me, since I may want to publish them independently later. I could use a path = "../lib" dependency during development, and switch to a versioned dependency when published, but does that require two separate GitHub repositories? How friendly is this setup with IDEs (specifically, VS Code) in terms of cross-navigation and editing?
I could probably tinker around with this until it worked, but I’m wondering what others have done in this situation. What is the “best practice” approach here?
If you want to work on them independently, and plan to release them as two different packages, a separate github repository would be easiest.
For example, if you have “my_library” as the alire library and “my_application” as the application, you could do something like:
(before you upload anything to github):
If you even publish your library (it would have to be before your app) you could just remoe the [[pins]]
If you don’t want to keep the application and library independent (maybe you want to always ship the library with the application) you don’t need to maintain two separate projects at all. Simply create a folder in your single alire project, ./src/my_library and ./src/my_application and edit the <yourporject.gpr> file with:
for Source_Dirs use ("src/",
"src/my_library",
"src/my_application",
"config/");
I believe I already tried your second suggestion, but it results in the message “main cannot be a source in a library project.” This was true despite the fact that the library never makes use of the main procedure or any application-specific packages. Merely having them in the Source_Dirs was enough to cause the error.
I haven’t tried two independent crates yet, but it sounds like you’re saying that’s the most appropriate way to handle my case. I just wasn’t sure how to create an appropriate temporary dependency from the application to the library while the crates live only in my file system and are not officially published artifacts.
Will VS Code understand the connection from the application to the library if I connect them the way you suggest (i.e., with [[pins]])? Wouldn’t I also have to with the library project in the application project to make VS Code aware of the library? Or does Alire take care of that magic somehow?
In my project coap_spark, I have a library in the root of the repository, and an application in the subdirectory client/. The client uses a pin to the library. I don’t know if this setup will suppose a problem if I decide to publish library and application, but for Alire, locally, is working fine.
Regarding VS Code, sometimes it’s a minor annoyance when you are working with the root of the repository, but you want to do something in the client, like compiling or proving it. In that case, either you resort to the command line, after changing directory, or you open a different VS Code instance in the client (code client/) and work with the two in parallel. On the other hand, in the client workspace, the VS Code instance will see the files from the library in terms of navigation, but then, since they are outside your workspace, you won’t be able to do all the possible operations from the IDE (like Git operations).
But I suppose, it makes totally sense to work with two workspaces, as they are two different projects/crates. Nevertheless, there could be better options that I haven’t investigated, like multiroot wokspaces.
Something else is afoot there then. Ada doesn’t technically have a “main”, any procedure can be the program entry point and can be named anything. So simply including the source for a main procedure shouldn’t be enough to trigger that error on its own. That error probably means you are mixing the rules for library gpr files and application gpr files together. If you truly want to go one gpr file, then you need to make it an application gpr file only and just add the library source file path as AJ suggested. You’ll want to make sure you remove any GPR options that are library specific or it could cause the compiler to think it is a library project only. What does your GPR file look like when you tried that option? Can you post it up here?
Sure! The entire GPR file is below. It was my intention to put the application in the app folder. With this configuration doing alr build unsurprisingly compiles the material in the app folder (including my app’s main procedure) and combines it all into the library… not a desired outcome. When I do alr build main I get the error about how the main procedure can’t be part of a library project.
It seems like two GPR files will be needed in some capacity. This leads to an additional question, though. If my library has tests and if my application has (separate) tests, do the tests need to be in their own crates too? The documentation on the Alire web site shows this structure for tests:
This suggests that one crate is nested inside another. Does every crate have its own Git repository? If so, this would seem to imply the use of Git submodules… or am I off the rails?
Here is that GPR file:
project Mediavision is
for Library_Name use "Mediavision";
for Library_Version use Project'Library_Name & ".so." & Mediavision_Config.Crate_Version;
for Source_Dirs use ("src/", "config/", "app/");
for Object_Dir use "obj/" & Mediavision_Config.Build_Profile;
for Create_Missing_Dirs use "True";
for Library_Dir use "lib";
type Library_Type_Type is ("relocatable", "static", "static-pic");
Library_Type : Library_Type_Type :=
external ("MEDIAVISION_LIBRARY_TYPE", external ("LIBRARY_TYPE", "static"));
for Library_Kind use Library_Type;
package Compiler is
for Default_Switches ("Ada") use Mediavision_Config.Ada_Compiler_Switches &
("-gnatyC", -- Check comments (single space version).
"-gnaty-B", -- Turn off the boolean operator check.
"-gnaty-I", -- Turn off prohibition against explicit 'in' mode.
"-gnatyM96", -- Set maximum allowed line lengths to 96 characters.
"-gnaty-t"); -- Turn off token spacing checks; they are too aggressive..
end Compiler;
package Binder is
for Switches ("Ada") use ("-Es"); -- Symbolic traceback
end Binder;
package Install is
for Artifacts (".") use ("share");
end Install;
end Mediavision;
I looked at your repository, and it seems like the organization and workflow you are using is very close, if not identical, to what I’m looking for. Thanks for sharing!
I also noticed that you have tests as a separate crate in the same repository, although it looks like your client tests are not directly managed by Alire (yes?). The prospect of running two instances of VS Code seems manageable, even if slightly awkward.
My library/application is far from publication ready, and I could postpone worrying about it util (if) that day comes. Alire might have additional capabilities by that time, anyway.
“.so” is Linux-specific and for relocatable library only. Gprbuild adds a correct file extension (.a, .so, .dll, .dylib) automatically.
For a “use-library-GPR” you need
for Externally_Built use "true";
and you will likely have different options e.g. ones you use to build the library and ones you want to force on an application that would use the library.
For the library tests, I’m using just the RecordFlux validator for the generated parser, simply launched from a Makefile. There is an Alire crate in the tests/ directory, but it is a leftover of following the pattern in ada_spark_workflow, but I should delete that Alire stuff, since it is not really used.
For the client tests (client/tests/), I’ve followed a black-box testing approach using bbt, so Alire isn’t involved there either.
Using the structure of your project as inspiration, I configured my project in a similar way and it seems to be working fine. I’m sure it will get adjusted in the future, but that’s okay. Anyway, thanks for your help!
The Alire project has a reference implementation that answers your question. See the project files for how they setup the library and an associated test crate.
That’s a good resource. Thanks for sharing. I’m happy to report that it looks like my project is pretty closely following that recommended structure insofar as testing is concerned.
It still seems to leave open the question of what the best practices are when a project consists of both a library and an associated application. Alire appears to assume that a crate is either one or the other, leading to structures where a single Git repository contains two crates (with their tests… four crates in total), or should the application and library (with their tests) be split across two repositories?
