[Exherbo-dev] On multibuild and PLATFORMS
moben at exherbo.org
Sun Jun 24 01:01:01 UTC 2012
On Sa, 2012-06-23 at 14:58 +0100, Ciaran McCreesh wrote:
> If you really want to do this, you'll need to figure out exactly how
> the "is it masked?" thing works. ...<snip>...
> And what does an option mask on such an option mean?
I assume you mean the 'masked by platform' thingy here.
You'd have to match TARGETS with your settings. If you don't -> masked
They might however be at-most-one, at-least-one or both.
> Do you just want to drop platforms.conf entirely?
Yes. noone has anything useful in there anyway.
> 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!
I am totally find with doing 's/C ABI/native target/g',
I think that's better anyway.
> > TARGETS="
> > C: amd64-32 amd64-64 x86
> > PYTHON: 2.5 2.6 2.7
> > "
> Is that a product or a coproduct?
just noting for the public:
As we discussed on irc yesterday, this probably needs to be decided at
least per target-class, if not even per package.
I would favor the later, since many will set TARGETS in an exlib anyway
(e.g. python, ruby) but it gives us more flexibility, should we need it.
But it probably makes sense to encode it either way, even if it is a
black box from the PM perspective.
> > - 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?
> > - 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?
> > - 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".
> Exherbo-dev mailing list
> Exherbo-dev at lists.exherbo.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: This is a digitally signed message part
More information about the Exherbo-dev