You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am in the process of building libadalang for Nix, which includes building gprbuild.
Nix packages are a bit special: they are built in what you could essentially call a sandbox (no network, no files but the ones specified as inputs, no environment but the one specified), and must put their output in a directory generated on the fly by the build system, after which the build output is copied to a readonly store with a unique path.
To build gprbuild, I first built the "bootstrap" version with the bootstrap script. It all went well, and the generated gprbuild worked just fine. This one lived at, say, /nix/store/0123-gprbuild-bootstrap/ (0123 standing for some unique hash).
I then attempted to use it to build gprbuild again, this time compiled by itself. The build worked, and this one lives at, say, /nix/store/4567-gprbuild/. But I got a bit of a surprise when trying to run it: it would keep failing, telling me it knew no compilers. After a bit of search, I found out it meant that gprbuild could not find the "knowledge base". Indeed, thinking back, while I passed it with the --with-kb argument to the bootstrap version, I have never declared it as a dependency to the second build.
I also figured out you could run gprbuild -v to know where the compiler is looking for that knowledge base. Indeed it was looking at the non-existent /nix/store/4567-gprbuild/share/gprconfig directory.
On the other hand, the bootstrap script had correctly created a /nix/store/1234-gprbuild-bootstrap/share/gprconfig directory, with all the XML files there, which explains why it succeeded while this version had trouble.
It is easy to circumvent the problem (for the curious: https://github.com/Ptival/nur-packages/blob/860cb7bf7981e3ea8dd919ff5343dfa1ad30d36c/pkgs/adaPackages/gprbuild/default.nix#L31-L32 )
My understanding is that this issue does not occur when all packages are writing to a shared location like /usr/share, since then the bootstrap version would populate /usr/share/gprconfig, and the the second build would stumble upon this pre-existing directory.
My question is:
do you intend for the Makefile-based build of gprbuild to be depending on a pre-installed gprconfig knowledge base?
or is there some way of pointing the Makefile to the knowledge base in such a way that it'd install it if missing?
The text was updated successfully, but these errors were encountered:
Actually, a convenient third option would be having a way to specify a folder where the knowledge base exists to the Makefile. Is this already feasible?
At the moment Makefile assumes that gprconfig kb has been pre-installed. I agree that supporting a case of external kb would add flexibility. Do you feel like proposing a pull request for that?
I am in the process of building libadalang for Nix, which includes building gprbuild.
Nix packages are a bit special: they are built in what you could essentially call a sandbox (no network, no files but the ones specified as inputs, no environment but the one specified), and must put their output in a directory generated on the fly by the build system, after which the build output is copied to a readonly store with a unique path.
To build gprbuild, I first built the "bootstrap" version with the bootstrap script. It all went well, and the generated gprbuild worked just fine. This one lived at, say,
/nix/store/0123-gprbuild-bootstrap/
(0123
standing for some unique hash).I then attempted to use it to build gprbuild again, this time compiled by itself. The build worked, and this one lives at, say,
/nix/store/4567-gprbuild/
. But I got a bit of a surprise when trying to run it: it would keep failing, telling me it knew no compilers. After a bit of search, I found out it meant that gprbuild could not find the "knowledge base". Indeed, thinking back, while I passed it with the--with-kb
argument to the bootstrap version, I have never declared it as a dependency to the second build.I also figured out you could run
gprbuild -v
to know where the compiler is looking for that knowledge base. Indeed it was looking at the non-existent/nix/store/4567-gprbuild/share/gprconfig
directory.On the other hand, the bootstrap script had correctly created a
/nix/store/1234-gprbuild-bootstrap/share/gprconfig
directory, with all the XML files there, which explains why it succeeded while this version had trouble.It is easy to circumvent the problem (for the curious: https://github.com/Ptival/nur-packages/blob/860cb7bf7981e3ea8dd919ff5343dfa1ad30d36c/pkgs/adaPackages/gprbuild/default.nix#L31-L32 )
My understanding is that this issue does not occur when all packages are writing to a shared location like
/usr/share
, since then the bootstrap version would populate/usr/share/gprconfig
, and the the second build would stumble upon this pre-existing directory.My question is:
The text was updated successfully, but these errors were encountered: