[Exherbo-dev] On multibuild and PLATFORMS
ciaran.mccreesh at googlemail.com
Sat Jun 23 13:58:16 UTC 2012
On Fri, 22 Jun 2012 20:50:50 +0200
Benedikt Morbach <moben at exherbo.org> wrote:
> This is now redundant with PLATFORMS, so I propose dropping PLATFORMS.
If you really want to do this, you'll need to figure out exactly how
the "is it masked?" thing works. Do you just want to drop
platforms.conf entirely? And what does an option mask on such an option
Also, what about things that aren't in the least bit C ABI related that
are platform dependent? Does the "C" name get used to mean "anything
that's a binary"? If that's the case, isn't "C ABI" a really stupid
pair of names?
> 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)
And you see why!
> 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
Is that a product or a coproduct?
> 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
> - In targets.conf you can select for which targets each exheres is
> built (options.conf like syntax)
Aren't TARGETS basically just syntax for fancy options? So wouldn't
reusing options.conf work?
> - 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)
I'm going to be mean here and ask how that interacts with the thing in
my head where "parts" are done as option dependencies where every
"part" is required to be on unless there's an explicit dep saying "and
I don't care about this part".
> - Maybe we want automatic injection of targets into MYOPTIONS, maybe
> we don't (like "target_C: amd64-32")
Oh, we do, we do. Otherwise you'll all be asking me for targetq and
target_with and so on...
Is there any reason we can't think of this stuff as just syntax around
slightly special options?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the Exherbo-dev