Home » Archived » 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  |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Specifying a combination for target.ws/os/arch [message #1005441 is a reply to message #1005431] |
Fri, 25 January 2013 13:04  |
 Henrik Lindberg
Messages: 2509
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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Specifying a combination for target.ws/os/arch [message #1005480 is a reply to message #1005470] |
Fri, 25 January 2013 15:46 |
|
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 #1005536 is a reply to message #1005487] |
Sat, 26 January 2013 08:56 |
|
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 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Specifying a combination for target.ws/os/arch [message #1007109 is a reply to message #1005579] |
Mon, 04 February 2013 13:37 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Specifying a combination for target.ws/os/arch [message #1011297 is a reply to message #1005579] |
Tue, 19 February 2013 09:05 |
|
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
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
|
|
|
| Re: Specifying a combination for target.ws/os/arch [message #1011362 is a reply to message #1011297] |
Tue, 19 February 2013 12:07 |
|
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
>>>
>>
>>
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 19:35:09 GMT 2024
Powered by FUDForum. Page generated in 0.03496 seconds |
] 
Search
Help
Register
Login
Home
