How to give access to the crate specific data files like CSS, Javascript, HTML, XML, SQL

[stcarrez]

Sometimes a crate can provide some data files which are also part of the component and
must be accessible at some point by the final application. Such files are not used during the
Ada compilation process, they are runtime files. Typical examples:

• HTML files,
• Stylesheet files (CSS),
• Javascript files,
• SQL database schemas,
• other application specific data files.

I struggled to find a way in a GNAT project to give access to these data files but
with gprbuild we can't even generate/configure a Ada file (like we could with gnatprep).
Using the GPR Install targets could work but we there is no way to run it from Alire
and it is probably necessary to define a target place for such installation.

We can't use the gprinstall default installation directory because we need a project-local directory (not a system directory like /usr/share)

[mosteo]

Right. I now remember we talked about this at FOSDEM. A couple of first thoughts:

• You can run gnatprep with a post-fetch action, but depending on the input you need this may not be enough I guess?
• Could the proposal at System externals to specify extra paths (C_INCLUDE_PATH, LIBRARY_PATH, PATH) #345 work if you want to export a path to some resources? Like, you can set a new MY_CRATE_RESOURCE_PATH=$root/resources, where $root is replaced by alr with the folder where the crate is deployed. This env var would consequently be available to other crates via gprbuild, gnatprep, or in the env that alr run sets (or will set) up.

[stcarrez]

The issue is to make available these resources to the final program.
Passing that to other crates is nice but not necessary (for me at least).

Always running the program through alr run is not practical and easy.
First, you can't debug your program easily and then if you want to install it, you still have the issue of
these crate specific resources located somewhere that you need.

For that purpose, I'm more in favor of allowing a crate to populate the alire/build directory if needed.

[mosteo]

So you'd like some way of copying folders from the crate into alire/build or some similar location (alire/share?).

[Fabien-Chouteau]

I tried to look at how Cargo solves this problem, what I can find so far is that it doesn't:

• https://www.reddit.com/r/rust/comments/4ivbjj/where_to_put_noncode_ressources_in_cargo_repos/
• https://users.rust-lang.org/t/packaging-assets-in-a-library-crate/4133/1
• https://www.reddit.com/r/rust/comments/ahsz9q/psa_if_the_examples_for_your_crate_rely_on_media/

[Fabien-Chouteau]

@stcarrez, autside of Alire what layout are you expecting when working/installing your application?

Seems to me that the application will always use a path that is either:

• hardcoded: /usr/share/whatever (potentially depending on --prefix of some kind)
• relative to the executable location: ../share/whatever

gprinstall can do that, and we already discussed whether or not alr should call gprinstall after gprbuild. We can also consider an assets field in the .toml where crate can specify folders to be copied in the build tree.

[stcarrez]

I don't think we must populate outside of Alire. For most of my projects, I install the additional files in
/usr/share/dynamo with other sub-directories for specific components. The rationale for this dynamo directory is that the dynamo tool is able to perform a number of tasks like merging SQL files, finding
dependencies which are not defined by GNAT projects (like a pure Javascript component).
OTOH, the Ada Keystore will install files in /usr/share/akt

If a component can install in some Alire share directory, that would be great I think.
The alire/share would be ok. In addition to that, if the component can set and update some
environment variable, that would be great. For a final application to work, it would need to
know where this alire/share/X directory is. The application could have defaults but by providing
an environment variable (or whatever) to the application will help.

[Fabien-Chouteau]

I don't think we must populate outside of Alire.

I am only considering the crate build tree inside the Alire directory.

For most of my projects, I install the additional files in /usr/share/dynamo

How do you get the path to this directory in your code? Relative to the path of the executable?

[stcarrez]

How do you get the path to this directory in your code? Relative to the path of the executable?

First, it's relative to the binary executable.
Then, it fallback to the hardcoded <prefix>/share/dynamo (in generated code with gnatprep).
Last, it can be overriden with a command line option.

[Fabien-Chouteau]

Then I think it makes sens to have an asset field in the toml that specified one or more files/directories to be copied at the root of the build tree before building (alire/build/).

[mosteo]

This has been addressed and in any case is superseded by #948