(moving to csound-dev as I think we may be annoying some people)

I also was not in favour of CsOptions, but we have it now and clearly
many people rely on it.

Another suggestion: we implement a tag

...

which is skipped if the name is not xxx.  The name could be an OS
name, or a user-defined name set with a command option.  Then one
could have different options for 32bit and 64 bit as well as for OS
differences, continent or whatever.
Whether this is a replacement fpr  or that is allowed
inside is also a question.

If we "agree" on a version that is not too complex (the if  stuff
is too hard) then it is a matter of a few minutes to implement.  What
we need is some consensus.

Sorry if I am not yet up to all messages on this; still reading
overnight mail and wanted to have my say before we charge into some
other ill-thought-out scheme.

==John ffitch



Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I would just change the syntax and semantics of .

(1) CsOptions takes an optional attribute, "command". The value of
this attribute is a user-defined command-line option, e.g.  means that Csound will look for --mycommand on
the command line. If found, the contents of CsOptions with that
attribute will be used. Alternatively, environment variable
CSOPTIONS=mycommand will be searched for.

(2) There may be more than one  element, but only if they
have "command" attributes with different values.

(3) If there is no --mycommand matching a CsOptions command attribute,
then the contents of the first (possibly only) CsOptions element will
be used. This preserves the present behavior.

Regards,
Mike

On 8/19/09, jpff  wrote:
> (moving to csound-dev as I think we may be annoying some people)
>
> I also was not in favour of CsOptions, but we have it now and clearly
> many people rely on it.
>
> Another suggestion: we implement a tag
> 
> ...
> 
> which is skipped if the name is not xxx.  The name could be an OS
> name, or a user-defined name set with a command option.  Then one
> could have different options for 32bit and 64 bit as well as for OS
> differences, continent or whatever.
> Whether this is a replacement fpr  or that is allowed
> inside is also a question.
>
> If we "agree" on a version that is not too complex (the if  stuff
> is too hard) then it is a matter of a few minutes to implement.  What
> we need is some consensus.
>
> Sorry if I am not yet up to all messages on this; still reading
> overnight mail and wanted to have my say before we charge into some
> other ill-thought-out scheme.
>
> ==John ffitch
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

Harder to implement that allowing multiple  and obeying them
sequentially, so default first then specialisations.
==John ff

> I would just change the syntax and semantics of .
>
> (1) CsOptions takes an optional attribute, "command". The value of
> this attribute is a user-defined command-line option, e.g.  command="mycommand"> means that Csound will look for --mycommand on
> the command line. If found, the contents of CsOptions with that
> attribute will be used. Alternatively, environment variable
> CSOPTIONS=mycommand will be searched for.
>
> (2) There may be more than one  element, but only if they
> have "command" attributes with different values.
>
> (3) If there is no --mycommand matching a CsOptions command attribute,
> then the contents of the first (possibly only) CsOptions element will
> be used. This preserves the present behavior.
>
> Regards,
> Mike
>
> On 8/19/09, jpff  wrote:
>> (moving to csound-dev as I think we may be annoying some people)
>>
>> I also was not in favour of CsOptions, but we have it now and clearly
>> many people rely on it.
>>
>> Another suggestion: we implement a tag
>> 
>> ...
>> 
>> which is skipped if the name is not xxx.  The name could be an OS
>> name, or a user-defined name set with a command option.  Then one
>> could have different options for 32bit and 64 bit as well as for OS
>> differences, continent or whatever.
>> Whether this is a replacement fpr  or that is allowed
>> inside is also a question.
>>
>> If we "agree" on a version that is not too complex (the if  stuff
>> is too hard) then it is a matter of a few minutes to implement.  What
>> we need is some consensus.
>>
>> Sorry if I am not yet up to all messages on this; still reading
>> overnight mail and wanted to have my say before we charge into some
>> other ill-thought-out scheme.
>>
>> ==John ffitch
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>




Send bugs reports to this list.
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"