Closed mosteo closed 2 years ago
I have a tool that can be made available to a dependent library with:
[environment]
PATH.append = "${CRATE_ROOT}/alire/build/bin"
Which is then used in a library as follows:
[[actions]]
type = "pre-build"
command = ["wayland_ada_scanner", "/usr/share/wayland/wayland.xml", "src/protocols"]
However I need to manually build the tool first, otherwise the pre-build action in the library fails.
I would expect alr to automatically build the tool dependency and make executables in the executables
array of the crate automatically available in dependent libraries without having to specify the PATH.append
environment.
Thanks @onox this is clearly one of the use cases that we want to address.
However I need to manually build the tool first
I'm unsure about what you mean by "manually build". Is it perhaps the current workaround: to force your tool to build in a post-fetch
action of the crate generating the tool?
I think it makes sense to incrementally build all dependencies in the order they're needed (this order is already applied to actions). Each build will find dependencies already built so it should incur not too much time penalty. I'm concerned that this can have some side-effect that I'm not seeing, though, when compared to launching a single build.
This automatic build could also be limited to dependencies declaring executables.
I would expect alr to automatically (...) make executables in the executables array of the crate automatically available
This is not trivially doable right now because executables are listed without paths. The rationale was that different build configurations may generate the same executable in different places. Rather than list all possible locations, that's how things stand right now. So, the final executable location is not known until it is built and it is recursively searched for in the build folder.
This in turn is compounded with our environment being generated at a single moment, before launching the build. So it is not possible to add executable paths automatically at that time. Instead, packagers have to provide them via environment
.
Changing this M.O. would have reaching consequences as you can see, so I'd like to see some consensus before touching this particular aspect (how executables are declared).
I think it makes sense to incrementally build all dependencies in the order they're needed (this order is already applied to actions). Each build will find dependencies already built so it should incur not too much time penalty. I'm concerned that this can have some side-effect that I'm not seeing, though, when compared to launching a single build.
I also think this is the way to go.
This is not trivially doable right now because executables are listed without paths. The rationale was that different build configurations may generate the same executable in different places. Rather than list all possible locations, that's how things stand right now. So, the final executable location is not known until it is built and it is recursively searched for in the build folder.
We can consider gprinstall
for exe dependencies. The executable will be in the bin/
dir.
We can consider
gprinstall
for exe dependencies. The executable will be in thebin/
dir.
Ah, well spotted. That would eliminate all the problems I listed.
I'm unsure about what you mean by "manually build". Is it perhaps the current workaround: to force your tool to build in a
post-fetch
action of the crate generating the tool?
What I meant is that I need to use a Makefile to first build the wayland_ada_scanner crate before running alr build
in the wayland_protocols_ada folder. See https://github.com/onox/wayland-ada/blob/master/Makefile
Implemented in #832
If I have a tool dependency, I want to be able to use it during pre-build actions
Related:
Related to #482