alire-project / alire

Command-line tool from the Alire project and supporting library
GNU General Public License v3.0
288 stars 49 forks source link

Make executables in dependencies available to dependents #628

Closed mosteo closed 2 years ago

mosteo commented 3 years ago

If I have a tool dependency, I want to be able to use it during pre-build actions

Related:

Related to #482

onox commented 3 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.

Fabien-Chouteau commented 3 years ago

Thanks @onox this is clearly one of the use cases that we want to address.

mosteo commented 3 years ago

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).

Fabien-Chouteau commented 3 years ago

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.

mosteo commented 3 years ago

We can consider gprinstall for exe dependencies. The executable will be in the bin/ dir.

Ah, well spotted. That would eliminate all the problems I listed.

onox commented 3 years ago

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

mosteo commented 2 years ago

Implemented in #832