Hi,
Following-up on a discussion on #exherbo, about expressing build-time
dependencies for cross-compiled packages (and Gentoo's new BDEPEND),
and where we ended at:
ciaranm | eh, implementing it should be easy
Previously there was some ML discussion on this subject (and more) [1]
and the multiarch-TODO [2] contains suggestions, so I'm adding the
previous protagonists in explicit CC.
As far as I understand it, the following consensus by the end:
- Introduce `build-time@native` and `build-time@target` labels
in the dependencies string.
- build-time@native is for packages that are only needed on the native
system (CBUILD in GNU/autotools parlance) to build a package or its
documentation, for example {cmake, *-config, yacc/bison, protoc,
tex}
- build-time@target is for packages that are only needed on the target
system (CHOST) to build a package, for example package
providing headers and static libraries.
The terminology is that in the multiarch-TODO.
- Consider that the current `build` label means, in the context of
cross-compilation, the union of `build-time@native` and `build-time@target`.
This means that too many packages (all for native and target) would
get built, but at least there is no chance of a build failing.
Conversely what happens when not cross-compiling for packages having
these finer-grained specs: it seems obvious that both `build-time@native`
and `build-time@target` shall be installed.
After reviewing additional materials I realize that we did not talk about:
- `build-cross` mentioned in the multiarch-TODO whose use case is
“cross compiling python needs a native python of the same SLOT,
icu needs native icu, etc“.
IMO this could be expressed by build-time@native: ${P_or_less_strict},
with the requirement that a dependency on self be ignored when not
cross-compiling.
We could also consider that a simple `build` adds
build-time@native: ${P}
so packagers that are not familiar with cross-compilation make working
-- albeit slower-to-build -- packages.
We did not talk about run-time dependencies, which are out of scope.
Next steps would be gathering feedback and greater consensus prior to
the “easy” implementation, which, if not done by core paludis developers,
would require some guidance/pointers.
Regards,
--
cJ
[1] http://lists.exherbo.org/pipermail/exherbo-dev/2016-February/thread.html
[2] https://exherbo.org/docs/multiarch-TODO.html#labels
_______________________________________________
Exherbo-dev mailing list
[email protected]
http://lists.exherbo.org/mailman/listinfo/exherbo-dev
