Writing about multibuild seems to be the new cool thing to annoy people in general and ciaranm especially, so I decided to give it a try :)
What we have
------------
If you don't remember it, you may want to read [1] first.
Also, we recently changed profiles to always force the default
multibuild_c target to on (i.e. 64 on amd64), so keep that in mind too.
The Problems
------------
1) The multibuild options are not specific enough. Being able to
build a 32bit lib on amd64 doesn't mean it works on ppc64.
2) The definition of the multibuild options is duplicated in every
exheres, which makes it harder to change or amend them.
3) DEPENDENCIES looks messy, because you have to add
[multibuild_c:*(-)?] to almost every single one.
Adding more multibuild classes won't make this any better.
This drastically lowers the signal to noise ratio.
The main point of this mail is 3), but to fix it, 1) is fixed too.
Preliminary Considerations
--------------------------
Apart from the initial "worked on x86" commit, we almost exclusively use
repository_mask.conf and not PLATFORMS to indicate stableness of things.
Thus, PLATFORMS is redundant and a maintenance burden.
The Proposal (aka: why am I still reading this?)
------------------------------------------------
Change the multibuild_c options to {platform}-{multibuild-target}. Like
this: amd64-64 or amd64-32
We create a new incremental metadata variable to hold those and future
multibuild cases.
This is now redundant with PLATFORMS, so I propose dropping PLATFORMS.
I am going to call this TARGETS from here on, but you can call it
whatever you want to call it, as long as it isn't ABIS.
(ciaranm will stab you for that)
This name may suck, because target is already used in multibuild.
Maybe it even makes sense to keep calling it PLATFORMS.
TARGETS looks like this:
TARGETS="
C: amd64-32 amd64-64 x86
PYTHON: 2.5 2.6 2.7
"
And works as follows:
- Your profile defines which targets are valid for you, forces
your default target on and does everything it currently does wrt
multibuild.
(though I would propose a format like unwritten-1 for the variables)
- In targets.conf you can select for which targets each exheres is
built (options.conf like syntax)
- For all the target-classes in an exheres, paludis appends
[target-class:*(?)?] to every dependency, unless specified
otherwise via an explicit dependency or a "take any" dependency
(someone come up with a syntax)
This did not work before, because not every C-family exheres was
multibuildified, so the (?) part produced missing deps.
With the above in place, everything has to have at least one target, so
this works now.
This makes DEPENDENCIES easy to read once again.
For non-multibuild, everything stays the same, because all it's
dependencies implicitly need the "default" target, which is always on.
For multibuild, you need to specify the ones which you don't need to be
built for your target, which are less most of the time.
Thoughts
--------
- Maybe we want to also allow targets in masks, thus making it
possible to indicate stable-ness on an architecture level.
- Maybe we want automatic injection of targets into MYOPTIONS, maybe
we don't (like "target_C: amd64-32")
- If we don't want that, we may want a new DEPENDENCIES syntax for
them, because they aren't options.
e.g. foo/bar{target_C: amd64-32}
- Maybe we want to drop the architecture specific C targets from
things were they should not matter.
Think pure python/shell/data exheres.
"Works on ~x86" never really made sense there.
(or at least it shouldn't)
- Maybe we want to move some/all of multibuild.exlib into paludis.
- Maybe we want to move the actual multibuild-y C targets
(i.e. amd64-32) into easy-multibuild.exlib
[1]
http://lists.exherbo.org/pipermail/exherbo-dev/2011-December/001012.html
(and following)
--
Benedikt Morbach
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
