Allow setting the GNATCOLL_ICONV_OPT environment variable in Makefile

[dalybrown]

This issue is similar to this one: #1289.

You should test to see if GNATCOLL_ICONV_OPT is set prior to setting it. The issue is here:

RecordFlux/Makefile

Line 318 in e1cf41e

$(GENERATED_DIR)/python/librflxlang/librflxlang.so: export GNATCOLL_ICONV_OPT := -v

Also, unrelated, but I think you need to include the path to gnatcoll in your GPR_PROJECT_PATH here: https://github.com/AdaCore/RecordFlux/blob/main/Makefile#L316. Otherwise, it won't find it. (I assume you happen to have gnatcoll installed already somewhere in your GPR_PROJECT_PATH.

[jklmnn]

I will fix the GNATCOLL_ICONV_OPT.

Also, unrelated, but I think you need to include the path to gnatcoll in your GPR_PROJECT_PATH.

Gnatcoll is included in both the GNAT Pro and GNAT Community toolchains and so far we never had problems with gnatcoll itself not being found. If you use a different gnatcoll you have to add it to the GPR_PROJECT_PATH. Note that we append our GPR_PROJECT_PATH in the Makefile so if you set it in your environment it should work (if not that's a bug in the Makefile).

Out of curiosity, which toolchain do you use? Maybe we can find a more flexible solution that works better for both our and your specific use case.

[dalybrown]

We started using Alire to manage our projects so we don't necessarily have some of the libraries like gnatcoll in the GPR_PROJECT_PATH automatically. The exception to this is that we don't use Alire to install gnat and gprbuild: we install those directly from apt in our Debian development environment (and therefore we use the FSF gnat).

The reason for not using Alire to install the compiler is people on our team use different architectures: I use a Mac M1, others use older X86_64 Intel Mac's, some use Linux laptops, Windows machines, etc. and when we first started using Alire it didn't support different architectures (maybe it does now?).

Everyone develops in a Debian docker container so we have a multi-arch base image with the basic tools installed that works natively on both architectures, and Alire takes over after that to install additional dependencies for each project (e.g., gnatcoll).

We were looking at the source code for RecordFlux to see how easy it would be to add some features we wanted (we'll contribute them back if we end up implementing them!) and ran into this issue when setting up the development environment. We are able to address this, but it seems like if you append the path to the gnatcoll bindings that is brought in via Alire, it might make sense to also append the path to gnatcoll too that is also brought in via Alire.

[jklmnn]

If you're using Debian, did you try to install libgnatcoll21-dev? IIRC this should work out of the box.

but it seems like if you append the path to the gnatcoll bindings that is brought in via Alire

The gnatcoll bindings referenced in the Makefile are from checked out repositories. If you run make init it will check out both gnatcoll-gmp and gnatcoll-iconv. We can't add a generic path for gnatcoll itself as its location depends on the toolchain used.

make init is also documented in our development guide.

[dalybrown]

So we are able to get everything working no problem: gnatcoll is available to us, it is just not in the GPR_PROJECT_PATH (it is automatically pulled in when you use alire to pull in the bindings...). We have a step prior where we add it to the path.

My suggestion was to update the Makefile and, similar to the gnatcoll bindings, append the path to gnatcoll that is pulled in via the alire dependencies instead of assuming it is already available on the system. This would make it more reproducible in my opinion. This is just me nitpicking :).

[dalybrown]

(This line here also brings in gnatcoll: https://github.com/AdaCore/RecordFlux/blob/main/Makefile#L239. You could add a similar line here for gnatcoll: https://github.com/AdaCore/RecordFlux/blob/main/Makefile#L308.)

[jklmnn]

I'm surprised that gnatcoll is not in the GPR_PROJECT_PATH provided by alire. Which alire version do you use? I just created a new crate and withed both gnatcoll_iconv and gnatcoll_gmp without explicitly adding gnatcoll and when I run alr printenv the GPR_PROJECT_PATH contains gnatcoll:

$ alr with gnatcoll_iconv gnatcoll_gmp
Requested changes:                                                       

   ✓ gnatcoll_iconv ^23.0.0 (add)
   ✓ gnatcoll_gmp   ^23.0.0 (add)
                                                              
Changes to dependency solution:

   +♼ gnat           12.2.1 (new,installed,gnat_native,indirect)
   +  gnatcoll       23.0.0 (new,indirect)                      
   +  gnatcoll_gmp   23.0.0 (new)                               
   +  gnatcoll_iconv 23.0.0 (new)                               
   +  libgmp         6.2.1  (new,indirect)                      
   +  libgpr         23.0.0 (new,indirect)                      
   +  xmlada         23.0.0 (new,indirect)                      

Do you want to proceed?
[Y] Yes  [N] No  (default is Yes) y
ⓘ Deploying libgmp=6.2.1...
ⓘ Deploying xmlada=23.0.0...
...                                                                                                                                                                                                                        
ⓘ Deploying gnatcoll=23.0.0...                                                                                                                                                                                                                          
ⓘ Deploying gnatcoll_gmp=23.0.0...
ⓘ Deploying gnatcoll_iconv=23.0.0...
...
$ /tmp/alr/test % alr printenv                        
export ALIRE="True"
export GNATCOLL_ALIRE_PREFIX="/tmp/alr/test/alire/cache/dependencies/gnatcoll_23.0.0_29478a20"
export GNATCOLL_BUILD_MODE="PROD"
export GNATCOLL_GMP_ALIRE_PREFIX="/tmp/alr/test/alire/cache/dependencies/gnatcoll_gmp_23.0.0_57de4a1a"
export GNATCOLL_ICONV_ALIRE_PREFIX="/tmp/alr/test/alire/cache/dependencies/gnatcoll_iconv_23.0.0_57de4a1a"
export GNATCOLL_ICONV_OPT="-v"
export GNATCOLL_OS="unix"
export GNATCOLL_VERSION="23.0.0"
export GPR_PROJECT_PATH="[...]:/tmp/alr/test\
   :/tmp/alr/test/alire/cache/dependencies/gnatcoll_23.0.0_29478a20\
   :/tmp/alr/test/alire/cache/dependencies/gnatcoll_gmp_23.0.0_57de4a1a/gmp\
   :/tmp/alr/test/alire/cache/dependencies/gnatcoll_iconv_23.0.0_57de4a1a/iconv\
   :/tmp/alr/test/alire/cache/dependencies/libgpr_23.0.0_34e332b9/gpr\
   :[...]
...

I'm running alire version 1.2.2 from January.

Also, at least to my understanding, gnatcoll-bindings does not contain gnatcoll itself. So https://github.com/AdaCore/RecordFlux/blob/main/Makefile#L239 does not bring in gnatcoll, it only adds the repository that includes the bindings for gmp and iconv (and others) but you still need gnatcoll itself.

Can you validate that alr with gnatcoll_iconv gnatcoll_gmp does not provide you with a proper GPR_PROJECT_PATH to gnatcoll? If that is the case that might be a bug in alire.

[dalybrown]

Hey,

So what you posted in your code snippet is the expected behaviour: alire will pull in transitive dependencies and flatten them in the dependencies folder (hence why you see gnatcoll there when you included gnatcoll_iconv and gnatcoll_gmp).

Alire will also modify the GPR_PROJECT_PATH to include all (transitive) dependencies when you are in an alire project (the presence of an alire.toml file makes that directory tree an alire project). So in your example above, gnatcoll is expected to be in the path when you are within an alire project.

However, alire does not permanently modify the GPR_PROJECT_PATH, so once you exit that directory tree it will no longer be set.

In regards to the issue I raised, I think I misunderstood what the install_gnat target was doing: I assumed that was where you were downloading the various dependencies required to build RecordFlux using alire. On further inspection, it seems like you are actually manually cloning dependencies (e.g., contrib/gnatcoll-bindings:) in addition to bringing them in via alire (e.g., alr -n with aunit gnatcoll_iconv gnatcoll_gmp).

The issue still stands that it assumes gnatcoll is available in the GPR_PROJECT_PATH whereas it makes no assumptions about the other dependencies and thus appends them.

I think you can clean up the dependency management (and therefore setting up the environment including GPR_PROJECT_PATH) using alire. You would save yourself from cloning the repos multiple times for some of the dependencies (e.g., alr -n with aunit gnatcoll_iconv gnatcoll_gmp and contrib/gnatcoll-bindings).

Hopefully this clarifies my issue and sorry for the confusion regarding some of the Makefile targets!

[jklmnn]

I think there are a few misunderstandings here, I'll try to clear things up a bit.

The Makefile aims to cover different toolchains. In particular these are GNAT Pro, GNAT Community and Alire. Both GNAT Pro and GNAT Community already provide gnatcoll which is the reason it is not included as a separately cloned dependency.

While Alire provides all the dependencies needed we cannot assume it is available in all circumstances so we cannot easily reference Alire dependencies in other make targets. What you can do is running eval $(alr printenv) to set the environment provided by Alire persistently. The install_gnat target is only meant to be used with Alire toolchains. If you use either GNAT Pro or GNAT Community you don't need to run that target. There is also printenv_gnat which is basically a wrapper around alr printenv so you could also run eval $(make printenv_gnat).

[dalybrown]

Ah ok - thanks! We will use the eval $(alr printenv) method.