[Exherbo-dev] On multibuild and PLATFORMS

Benedikt Morbach moben at exherbo.org
Fri Jun 22 18:50:50 UTC 2012

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:

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


  - 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

(and following)

Benedikt Morbach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.exherbo.org/pipermail/exherbo-dev/attachments/20120622/6f528a29/attachment.asc>

More information about the Exherbo-dev mailing list