[Exherbo-dev] Labels - cross and granularity
Bo Ørsted Andresen
zlin at exherbo.org
Wed Feb 3 22:52:08 UTC 2016
When trying to cross compile I have been coming across some packages
that have build: dependencies which are required both on the build
system and on the target system at build time - but should be safe to
For cross build: dependencies are pulled in only on the build system
while run: dependencies are pulled in on both. As such all we can
currently do to fix above mentioned packages is to make them build+run:
dependencies and thus forcing them to be pulled in by pbins and kept
when not building.
A lot of these dependencies, I've been running into are proto headers.
It's possible that a better match for those is the built-against: label.
The description for built-against: is useless, which in turn makes it
useless overall, because we all need to understand exactly when to use
a label in order to decide when it is correct to use. Furthermore the
implementation for built-against: is currently identical to the
implementation for build+run: in combination, so it does not actually
provide any granularity that build+run: does not provide.
Therefore is follows that built-against: should either have its
implementation and description improved, or we should remove it because
it does not provide us with anything.
For the build required on both build system and target system we need
one or more new labels. Three proposals seem to be circulating:
1) Just add a new label for this kind of build. What should it be
called? All I can think of is target-build: or similar.
2) Change all our labels from defining when a dependency is used to
defining how it is used. E.g. read:, import:, link:, exec:, etc.
If this needs more fleshing out, I'll leave that to eternaleye..
This might provide a lot of additional granularity but may also make
the common case too complicated?
3) Add host and target orthogonally to the existing labels. E.g.
build+run*target:, build*target:, build+run*host:, build*host:, etc.
If we go with this it may make sense to limit the number of labels it
can be combined with? suggestion*host: does not strike me as making a
lot of sense.
Anybody have other ideas? Or suggestions for a good name for 1) ? Or
other cases for which we currently lack the granularity, but know of a
real world use case?
Bo Ørsted Andresen
More information about the Exherbo-dev