Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Buckminster » Specifying a combination for target.ws/os/arch
Specifying a combination for target.ws/os/arch [message #1005431] Fri, 25 January 2013 12:26 Go to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1418
Registered: July 2009
Senior Member
Hi

a similar question was posted in this newsgroup, but I have a slightly
different context, though it's related to the possibility of specify
combination for target.os/ws/arch:

say that I want to build my site (and my products) only for these
combinations

os="linux,macosx,win32"
ws="cocoa,gtk,win32"
arch="x86,x86_64"

during materialization (of the TP) I cannot specify a combination in the
cquery for the desired os.ws.arch (I tried with LDAP filters but they
don't work) but I can exclude the other architectures
with advisor nodes, e.g.,

<cq:advisorNode namePattern=".*\.solaris.*" skipComponent="true"/>

and, then equinox launchers (for instance) are not included for these
architectures...

but then, when I build the site.p2 (for later product installation) I
cannot specify the desired combinations: I can only specify in the
properties file

target.os=*
target.ws=*
target.arch=*

and the action fails due to

No component named
org.eclipse.equinox.launcher.gtk.solaris.sparc:osgi.bundle/[1.1.200.v20120522-1813,1.1.200.v20120522-1813](&(target.arch=sparc)(target.os=solaris)(target.ws=gtk))
is known to Buckminster

how could then avoid this problem?

rationale: I'd have no problem in getting into the TP and in the site.p2
all available combinations, but I'd like to materialize the TP against a
local mirror built with the b3 aggregator (and possibly install the
products reusing this mirror), and, as far as I understand, in the
b3aggr you must specify manually all valid architecture combinations,
you can't just say * (and I'd like to avoid specifying here also the
combinations I'm not interested in).

thanks in advance
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Re: Specifying a combination for target.ws/os/arch [message #1005441 is a reply to message #1005431] Fri, 25 January 2013 13:04 Go to previous messageGo to next message
Henrik Lindberg is currently offline Henrik LindbergFriend
Messages: 2501
Registered: July 2009
Senior Member
I suspect the problem is that * expands to a set of known values as
opposed to "values of the things that are available". But I am only
guessing...

- henrik

On 2013-25-01 13:26, Lorenzo Bettini wrote:
> Hi
>
> a similar question was posted in this newsgroup, but I have a slightly
> different context, though it's related to the possibility of specify
> combination for target.os/ws/arch:
>
> say that I want to build my site (and my products) only for these
> combinations
>
> os="linux,macosx,win32"
> ws="cocoa,gtk,win32"
> arch="x86,x86_64"
>
> during materialization (of the TP) I cannot specify a combination in the
> cquery for the desired os.ws.arch (I tried with LDAP filters but they
> don't work) but I can exclude the other architectures
> with advisor nodes, e.g.,
>
> <cq:advisorNode namePattern=".*\.solaris.*" skipComponent="true"/>
>
> and, then equinox launchers (for instance) are not included for these
> architectures...
>
> but then, when I build the site.p2 (for later product installation) I
> cannot specify the desired combinations: I can only specify in the
> properties file
>
> target.os=*
> target.ws=*
> target.arch=*
>
> and the action fails due to
>
> No component named
> org.eclipse.equinox.launcher.gtk.solaris.sparc:osgi.bundle/[1.1.200.v20120522-1813,1.1.200.v20120522-1813](&(target.arch=sparc)(target.os=solaris)(target.ws=gtk))
> is known to Buckminster
>
> how could then avoid this problem?
>
> rationale: I'd have no problem in getting into the TP and in the site.p2
> all available combinations, but I'd like to materialize the TP against a
> local mirror built with the b3 aggregator (and possibly install the
> products reusing this mirror), and, as far as I understand, in the
> b3aggr you must specify manually all valid architecture combinations,
> you can't just say * (and I'd like to avoid specifying here also the
> combinations I'm not interested in).
>
> thanks in advance
> Lorenzo
>
Re: Specifying a combination for target.ws/os/arch [message #1005470 is a reply to message #1005441] Fri, 25 January 2013 15:06 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1418
Registered: July 2009
Senior Member
Would it make sense to make it possible to specify for target.os/arch/ws
some kind of ldap filter (which from what I understand is used somewhere
else)?

cheers
Lorenzo

On 01/25/2013 02:04 PM, Henrik Lindberg wrote:
> I suspect the problem is that * expands to a set of known values as
> opposed to "values of the things that are available". But I am only
> guessing...
>
> - henrik
>
> On 2013-25-01 13:26, Lorenzo Bettini wrote:
>> Hi
>>
>> a similar question was posted in this newsgroup, but I have a slightly
>> different context, though it's related to the possibility of specify
>> combination for target.os/ws/arch:
>>
>> say that I want to build my site (and my products) only for these
>> combinations
>>
>> os="linux,macosx,win32"
>> ws="cocoa,gtk,win32"
>> arch="x86,x86_64"
>>
>> during materialization (of the TP) I cannot specify a combination in the
>> cquery for the desired os.ws.arch (I tried with LDAP filters but they
>> don't work) but I can exclude the other architectures
>> with advisor nodes, e.g.,
>>
>> <cq:advisorNode namePattern=".*\.solaris.*" skipComponent="true"/>
>>
>> and, then equinox launchers (for instance) are not included for these
>> architectures...
>>
>> but then, when I build the site.p2 (for later product installation) I
>> cannot specify the desired combinations: I can only specify in the
>> properties file
>>
>> target.os=*
>> target.ws=*
>> target.arch=*
>>
>> and the action fails due to
>>
>> No component named
>> org.eclipse.equinox.launcher.gtk.solaris.sparc:osgi.bundle/[1.1.200.v20120522-1813,1.1.200.v20120522-1813](&(target.arch=sparc)(target.os=solaris)(target.ws=gtk))
>>
>> is known to Buckminster
>>
>> how could then avoid this problem?
>>
>> rationale: I'd have no problem in getting into the TP and in the site.p2
>> all available combinations, but I'd like to materialize the TP against a
>> local mirror built with the b3 aggregator (and possibly install the
>> products reusing this mirror), and, as far as I understand, in the
>> b3aggr you must specify manually all valid architecture combinations,
>> you can't just say * (and I'd like to avoid specifying here also the
>> combinations I'm not interested in).
>>
>> thanks in advance
>> Lorenzo
>>
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Re: Specifying a combination for target.ws/os/arch [message #1005480 is a reply to message #1005470] Fri, 25 January 2013 15:46 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
On 2013-01-25 16:06, Lorenzo Bettini wrote:
> Would it make sense to make it possible to specify for target.os/arch/ws
> some kind of ldap filter (which from what I understand is used somewhere
> else)?
>
The os/ws/arch are used as input to LDAP filters in various places.
They cannot be LDAP filters themselves. The LDAP evaluator that
Buckminster uses have special treatment for the wildcard value '*' so
that a comparison with it always yields true.

There is no way to pass sequences of values. No LDAP filter expects that.

- thomas



> cheers
> Lorenzo
>
> On 01/25/2013 02:04 PM, Henrik Lindberg wrote:
>> I suspect the problem is that * expands to a set of known values as
>> opposed to "values of the things that are available". But I am only
>> guessing...
>>
>> - henrik
>>
>> On 2013-25-01 13:26, Lorenzo Bettini wrote:
>>> Hi
>>>
>>> a similar question was posted in this newsgroup, but I have a slightly
>>> different context, though it's related to the possibility of specify
>>> combination for target.os/ws/arch:
>>>
>>> say that I want to build my site (and my products) only for these
>>> combinations
>>>
>>> os="linux,macosx,win32"
>>> ws="cocoa,gtk,win32"
>>> arch="x86,x86_64"
>>>
>>> during materialization (of the TP) I cannot specify a combination in the
>>> cquery for the desired os.ws.arch (I tried with LDAP filters but they
>>> don't work) but I can exclude the other architectures
>>> with advisor nodes, e.g.,
>>>
>>> <cq:advisorNode namePattern=".*\.solaris.*" skipComponent="true"/>
>>>
>>> and, then equinox launchers (for instance) are not included for these
>>> architectures...
>>>
>>> but then, when I build the site.p2 (for later product installation) I
>>> cannot specify the desired combinations: I can only specify in the
>>> properties file
>>>
>>> target.os=*
>>> target.ws=*
>>> target.arch=*
>>>
>>> and the action fails due to
>>>
>>> No component named
>>> org.eclipse.equinox.launcher.gtk.solaris.sparc:osgi.bundle/[1.1.200.v20120522-1813,1.1.200.v20120522-1813](&(target.arch=sparc)(target.os=solaris)(target.ws=gtk))
>>>
>>> is known to Buckminster
>>>
>>> how could then avoid this problem?
>>>
>>> rationale: I'd have no problem in getting into the TP and in the site.p2
>>> all available combinations, but I'd like to materialize the TP against a
>>> local mirror built with the b3 aggregator (and possibly install the
>>> products reusing this mirror), and, as far as I understand, in the
>>> b3aggr you must specify manually all valid architecture combinations,
>>> you can't just say * (and I'd like to avoid specifying here also the
>>> combinations I'm not interested in).
>>>
>>> thanks in advance
>>> Lorenzo
>>>
>>
>
>
Re: Specifying a combination for target.ws/os/arch [message #1005487 is a reply to message #1005480] Fri, 25 January 2013 16:04 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1418
Registered: July 2009
Senior Member
On 01/25/2013 04:46 PM, Thomas Hallgren wrote:
> On 2013-01-25 16:06, Lorenzo Bettini wrote:
>> Would it make sense to make it possible to specify for target.os/arch/ws
>> some kind of ldap filter (which from what I understand is used somewhere
>> else)?
>>
> The os/ws/arch are used as input to LDAP filters in various places. They
> cannot be LDAP filters themselves. The LDAP evaluator that Buckminster
> uses have special treatment for the wildcard value '*' so that a
> comparison with it always yields true.
>
> There is no way to pass sequences of values. No LDAP filter expects that.
>

and if a sequence is splitted and each portion is matched against the
filter one by one?

cheers
Lorenzo

--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Re: Specifying a combination for target.ws/os/arch [message #1005536 is a reply to message #1005487] Sat, 26 January 2013 08:56 Go to previous messageGo to next message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
On 2013-01-25 17:04, Lorenzo Bettini wrote:
> On 01/25/2013 04:46 PM, Thomas Hallgren wrote:
>> On 2013-01-25 16:06, Lorenzo Bettini wrote:
>>> Would it make sense to make it possible to specify for target.os/arch/ws
>>> some kind of ldap filter (which from what I understand is used somewhere
>>> else)?
>>>
>> The os/ws/arch are used as input to LDAP filters in various places. They
>> cannot be LDAP filters themselves. The LDAP evaluator that Buckminster
>> uses have special treatment for the wildcard value '*' so that a
>> comparison with it always yields true.
>>
>> There is no way to pass sequences of values. No LDAP filter expects that.
>>
>
> and if a sequence is splitted and each portion is matched against the
> filter one by one?
>
Well, I suppose the LDAP evaluator could be rewritten to do that, but
then you will run into other problems. Suppose you have a filter like:

(&(os=win32)(ws=win32))

You pass it this:

os=win32,linux
ws=win32,gtk

You will end up with this:

os=win32, ws=gtk
os=win32, ws=win32
os=linux, ws=gtk
os=linux, ws=win32

All four combos will yield true for the filter. I don't think that's
what you want. The adding arch to the mix will expand the matrix even
more and most of the comparisons will be invalid.

We could of course impose "value declaration order" and "value
declaration count", i.e. give the order of declaration semantic
significance and require that each property contains the exact same
number of values. But then we're need to do that for each multi-property
for which there is the slightest chance the it might occur in an LDAP
expression together with an other multi-property. So os,ws,arch for
sure, but also lang and possibly others that we don't control. I think
that would open up a can of worms.

- thomas
Re: Specifying a combination for target.ws/os/arch [message #1005579 is a reply to message #1005536] Sat, 26 January 2013 18:40 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1418
Registered: July 2009
Senior Member
Hi Thomas

sorry for my bad explanation; I actually meant something like grouping
environment specifications in some kinds of triplets to specify many
environment configurations, e.g., grouping target.os, target.ws,
target.arch into a single property; something like

target.environments=(x86,linux,gtk),(x86_64,linux,gtk),(x86,win32,win32)

so that the combinations (environment configurations) are actually fixed.

An alternative solution would be that if site.p2 action gets * as
specifications for os,arch,ws, then it could simply use things in the
target platform and not complain about a missing configuration.

Otherwise, at the moment, if you don't have all configurations in the
target platform, you can still create products for different
configurations (one at time), but you cannot build a p2 repository for
more than one configuration.

If I understand correctly, for instance:
running site.p2 with
target.os=linux target.ws=gtk target.arch=x86_64
and then with
target.os=win32 target.ws=win32 target.arch=x86_64
will overwrite the binary artifacts of the previous configuration, right?

cheers
Lorenzo

On 01/26/2013 09:56 AM, Thomas Hallgren wrote:
> On 2013-01-25 17:04, Lorenzo Bettini wrote:
>> On 01/25/2013 04:46 PM, Thomas Hallgren wrote:
>>> On 2013-01-25 16:06, Lorenzo Bettini wrote:
>>>> Would it make sense to make it possible to specify for
>>>> target.os/arch/ws
>>>> some kind of ldap filter (which from what I understand is used
>>>> somewhere
>>>> else)?
>>>>
>>> The os/ws/arch are used as input to LDAP filters in various places. They
>>> cannot be LDAP filters themselves. The LDAP evaluator that Buckminster
>>> uses have special treatment for the wildcard value '*' so that a
>>> comparison with it always yields true.
>>>
>>> There is no way to pass sequences of values. No LDAP filter expects
>>> that.
>>>
>>
>> and if a sequence is splitted and each portion is matched against the
>> filter one by one?
>>
> Well, I suppose the LDAP evaluator could be rewritten to do that, but
> then you will run into other problems. Suppose you have a filter like:
>
> (&(os=win32)(ws=win32))
>
> You pass it this:
>
> os=win32,linux
> ws=win32,gtk
>
> You will end up with this:
>
> os=win32, ws=gtk
> os=win32, ws=win32
> os=linux, ws=gtk
> os=linux, ws=win32
>
> All four combos will yield true for the filter. I don't think that's
> what you want. The adding arch to the mix will expand the matrix even
> more and most of the comparisons will be invalid.
>
> We could of course impose "value declaration order" and "value
> declaration count", i.e. give the order of declaration semantic
> significance and require that each property contains the exact same
> number of values. But then we're need to do that for each multi-property
> for which there is the slightest chance the it might occur in an LDAP
> expression together with an other multi-property. So os,ws,arch for
> sure, but also lang and possibly others that we don't control. I think
> that would open up a can of worms.
>
> - thomas
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Re: Specifying a combination for target.ws/os/arch [message #1007109 is a reply to message #1005579] Mon, 04 February 2013 13:37 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1418
Registered: July 2009
Senior Member
any comment on this possible solution?

On 01/26/2013 07:40 PM, Lorenzo Bettini wrote:
> Hi Thomas
>
> sorry for my bad explanation; I actually meant something like grouping
> environment specifications in some kinds of triplets to specify many
> environment configurations, e.g., grouping target.os, target.ws,
> target.arch into a single property; something like
>
> target.environments=(x86,linux,gtk),(x86_64,linux,gtk),(x86,win32,win32)
>
> so that the combinations (environment configurations) are actually fixed.
>
> An alternative solution would be that if site.p2 action gets * as
> specifications for os,arch,ws, then it could simply use things in the
> target platform and not complain about a missing configuration.
>
> Otherwise, at the moment, if you don't have all configurations in the
> target platform, you can still create products for different
> configurations (one at time), but you cannot build a p2 repository for
> more than one configuration.
>
> If I understand correctly, for instance:
> running site.p2 with
> target.os=linux target.ws=gtk target.arch=x86_64
> and then with
> target.os=win32 target.ws=win32 target.arch=x86_64
> will overwrite the binary artifacts of the previous configuration, right?
>
> cheers
> Lorenzo
>
> On 01/26/2013 09:56 AM, Thomas Hallgren wrote:
>> On 2013-01-25 17:04, Lorenzo Bettini wrote:
>>> On 01/25/2013 04:46 PM, Thomas Hallgren wrote:
>>>> On 2013-01-25 16:06, Lorenzo Bettini wrote:
>>>>> Would it make sense to make it possible to specify for
>>>>> target.os/arch/ws
>>>>> some kind of ldap filter (which from what I understand is used
>>>>> somewhere
>>>>> else)?
>>>>>
>>>> The os/ws/arch are used as input to LDAP filters in various places. They
>>>> cannot be LDAP filters themselves. The LDAP evaluator that Buckminster
>>>> uses have special treatment for the wildcard value '*' so that a
>>>> comparison with it always yields true.
>>>>
>>>> There is no way to pass sequences of values. No LDAP filter expects
>>>> that.
>>>>
>>>
>>> and if a sequence is splitted and each portion is matched against the
>>> filter one by one?
>>>
>> Well, I suppose the LDAP evaluator could be rewritten to do that, but
>> then you will run into other problems. Suppose you have a filter like:
>>
>> (&(os=win32)(ws=win32))
>>
>> You pass it this:
>>
>> os=win32,linux
>> ws=win32,gtk
>>
>> You will end up with this:
>>
>> os=win32, ws=gtk
>> os=win32, ws=win32
>> os=linux, ws=gtk
>> os=linux, ws=win32
>>
>> All four combos will yield true for the filter. I don't think that's
>> what you want. The adding arch to the mix will expand the matrix even
>> more and most of the comparisons will be invalid.
>>
>> We could of course impose "value declaration order" and "value
>> declaration count", i.e. give the order of declaration semantic
>> significance and require that each property contains the exact same
>> number of values. But then we're need to do that for each multi-property
>> for which there is the slightest chance the it might occur in an LDAP
>> expression together with an other multi-property. So os,ws,arch for
>> sure, but also lang and possibly others that we don't control. I think
>> that would open up a can of worms.
>>
>> - thomas
>>
>
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Re: Specifying a combination for target.ws/os/arch [message #1011297 is a reply to message #1005579] Tue, 19 February 2013 09:05 Go to previous messageGo to next message
Lorenzo Bettini is currently offline Lorenzo BettiniFriend
Messages: 1418
Registered: July 2009
Senior Member
any comment?

On 01/26/2013 07:40 PM, Lorenzo Bettini wrote:
> Hi Thomas
>
> sorry for my bad explanation; I actually meant something like grouping
> environment specifications in some kinds of triplets to specify many
> environment configurations, e.g., grouping target.os, target.ws,
> target.arch into a single property; something like
>
> target.environments=(x86,linux,gtk),(x86_64,linux,gtk),(x86,win32,win32)
>
> so that the combinations (environment configurations) are actually fixed.
>
> An alternative solution would be that if site.p2 action gets * as
> specifications for os,arch,ws, then it could simply use things in the
> target platform and not complain about a missing configuration.
>
> Otherwise, at the moment, if you don't have all configurations in the
> target platform, you can still create products for different
> configurations (one at time), but you cannot build a p2 repository for
> more than one configuration.
>
> If I understand correctly, for instance:
> running site.p2 with
> target.os=linux target.ws=gtk target.arch=x86_64
> and then with
> target.os=win32 target.ws=win32 target.arch=x86_64
> will overwrite the binary artifacts of the previous configuration, right?
>
> cheers
> Lorenzo
>
> On 01/26/2013 09:56 AM, Thomas Hallgren wrote:
>> On 2013-01-25 17:04, Lorenzo Bettini wrote:
>>> On 01/25/2013 04:46 PM, Thomas Hallgren wrote:
>>>> On 2013-01-25 16:06, Lorenzo Bettini wrote:
>>>>> Would it make sense to make it possible to specify for
>>>>> target.os/arch/ws
>>>>> some kind of ldap filter (which from what I understand is used
>>>>> somewhere
>>>>> else)?
>>>>>
>>>> The os/ws/arch are used as input to LDAP filters in various places. They
>>>> cannot be LDAP filters themselves. The LDAP evaluator that Buckminster
>>>> uses have special treatment for the wildcard value '*' so that a
>>>> comparison with it always yields true.
>>>>
>>>> There is no way to pass sequences of values. No LDAP filter expects
>>>> that.
>>>>
>>>
>>> and if a sequence is splitted and each portion is matched against the
>>> filter one by one?
>>>
>> Well, I suppose the LDAP evaluator could be rewritten to do that, but
>> then you will run into other problems. Suppose you have a filter like:
>>
>> (&(os=win32)(ws=win32))
>>
>> You pass it this:
>>
>> os=win32,linux
>> ws=win32,gtk
>>
>> You will end up with this:
>>
>> os=win32, ws=gtk
>> os=win32, ws=win32
>> os=linux, ws=gtk
>> os=linux, ws=win32
>>
>> All four combos will yield true for the filter. I don't think that's
>> what you want. The adding arch to the mix will expand the matrix even
>> more and most of the comparisons will be invalid.
>>
>> We could of course impose "value declaration order" and "value
>> declaration count", i.e. give the order of declaration semantic
>> significance and require that each property contains the exact same
>> number of values. But then we're need to do that for each multi-property
>> for which there is the slightest chance the it might occur in an LDAP
>> expression together with an other multi-property. So os,ws,arch for
>> sure, but also lang and possibly others that we don't control. I think
>> that would open up a can of worms.
>>
>> - thomas
>>
>
>


--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it
Re: Specifying a combination for target.ws/os/arch [message #1011362 is a reply to message #1011297] Tue, 19 February 2013 12:07 Go to previous message
Thomas Hallgren is currently offline Thomas HallgrenFriend
Messages: 3232
Registered: July 2009
Senior Member
My only comment at this point is that this would be far from trivial to
implement. But I'd be willing to review a patch if you care to submit one.

- thomas

On 2013-02-19 10:05, Lorenzo Bettini wrote:
> any comment?
>
> On 01/26/2013 07:40 PM, Lorenzo Bettini wrote:
>> Hi Thomas
>>
>> sorry for my bad explanation; I actually meant something like grouping
>> environment specifications in some kinds of triplets to specify many
>> environment configurations, e.g., grouping target.os, target.ws,
>> target.arch into a single property; something like
>>
>> target.environments=(x86,linux,gtk),(x86_64,linux,gtk),(x86,win32,win32)
>>
>> so that the combinations (environment configurations) are actually fixed.
>>
>> An alternative solution would be that if site.p2 action gets * as
>> specifications for os,arch,ws, then it could simply use things in the
>> target platform and not complain about a missing configuration.
>>
>> Otherwise, at the moment, if you don't have all configurations in the
>> target platform, you can still create products for different
>> configurations (one at time), but you cannot build a p2 repository for
>> more than one configuration.
>>
>> If I understand correctly, for instance:
>> running site.p2 with
>> target.os=linux target.ws=gtk target.arch=x86_64
>> and then with
>> target.os=win32 target.ws=win32 target.arch=x86_64
>> will overwrite the binary artifacts of the previous configuration, right?
>>
>> cheers
>> Lorenzo
>>
>> On 01/26/2013 09:56 AM, Thomas Hallgren wrote:
>>> On 2013-01-25 17:04, Lorenzo Bettini wrote:
>>>> On 01/25/2013 04:46 PM, Thomas Hallgren wrote:
>>>>> On 2013-01-25 16:06, Lorenzo Bettini wrote:
>>>>>> Would it make sense to make it possible to specify for
>>>>>> target.os/arch/ws
>>>>>> some kind of ldap filter (which from what I understand is used
>>>>>> somewhere
>>>>>> else)?
>>>>>>
>>>>> The os/ws/arch are used as input to LDAP filters in various places. They
>>>>> cannot be LDAP filters themselves. The LDAP evaluator that Buckminster
>>>>> uses have special treatment for the wildcard value '*' so that a
>>>>> comparison with it always yields true.
>>>>>
>>>>> There is no way to pass sequences of values. No LDAP filter expects
>>>>> that.
>>>>>
>>>>
>>>> and if a sequence is splitted and each portion is matched against the
>>>> filter one by one?
>>>>
>>> Well, I suppose the LDAP evaluator could be rewritten to do that, but
>>> then you will run into other problems. Suppose you have a filter like:
>>>
>>> (&(os=win32)(ws=win32))
>>>
>>> You pass it this:
>>>
>>> os=win32,linux
>>> ws=win32,gtk
>>>
>>> You will end up with this:
>>>
>>> os=win32, ws=gtk
>>> os=win32, ws=win32
>>> os=linux, ws=gtk
>>> os=linux, ws=win32
>>>
>>> All four combos will yield true for the filter. I don't think that's
>>> what you want. The adding arch to the mix will expand the matrix even
>>> more and most of the comparisons will be invalid.
>>>
>>> We could of course impose "value declaration order" and "value
>>> declaration count", i.e. give the order of declaration semantic
>>> significance and require that each property contains the exact same
>>> number of values. But then we're need to do that for each multi-property
>>> for which there is the slightest chance the it might occur in an LDAP
>>> expression together with an other multi-property. So os,ws,arch for
>>> sure, but also lang and possibly others that we don't control. I think
>>> that would open up a can of worms.
>>>
>>> - thomas
>>>
>>
>>
>
>
Previous Topic:GitProvider related error in CI job
Next Topic:CSpec org.junit:osgi has no action, group, or local artifact named bundle.jars
Goto Forum:
  


Current Time: Sun Dec 21 09:31:08 GMT 2014

Powered by FUDForum. Page generated in 0.11717 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software