Closed dalybrown closed 11 months ago
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.
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.
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.
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 :).
(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.)
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.
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!
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)
.
Ah ok - thanks! We will use the eval $(alr printenv)
method.
This issue is similar to this one: https://github.com/AdaCore/RecordFlux/issues/1289.
You should test to see if
GNATCOLL_ICONV_OPT
is set prior to setting it. The issue is here: https://github.com/AdaCore/RecordFlux/blob/e1cf41ea179a282131621e5fa1f163be9e53c5c6/Makefile#L318Also, unrelated, but I think you need to include the path to
gnatcoll
in yourGPR_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 yourGPR_PROJECT_PATH
.