Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...))
| Date | 2008-04-04 09:29 |
| From | victor |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
These are the lines of interest for you:
517 onwards===========================
elif getPlatform() == 'darwin':
vers = (int(sys.hexversion) >> 24, (int(sys.hexversion) >> 16) & 255)
if vers[1] == 3:
print "Python version is 2.%s, using Apple Python Framework" %
vers[1]
pyBasePath = '/System/Library/Frameworks/Python.framework'
else:
print "Python version is 2.%s, using MacPython Framework" % vers[1]
pyBasePath = '/Library/Frameworks/Python.Framework'
I was assuming, and this is prior to 10.5, that Apple's Python is 2.3; if
not we're
running MacPython. But if Apple's framework is 2.5, then this code doesn't
work.
(I don't have 10.5 here and if I had, then I would not be able to produce
10.4
binaries easily (ie. without leaving my office...).) But I suppose I will
have to bite
the bullet and pay Apple's upgrade tax.
The more I use proprietary software, the more I grow fond of Free.
Victor
----- Original Message -----
From: "DavidW" |
| Date | 2008-04-04 13:07 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
Hi V,
I'll wait for Felipe then b4 refactoring. Perhaps he can bear in mind
the issues I've raised.
I _do_ understand your position on 2.5/2.3 etc and I'm not trying to
pressure you!
However I haven't had a csnd system for a while and the pressure of
work mounts.
After all, ultimately what we need is a way of being able to build to
whatever the local conditions are.
There are very interesting versions of python out there, for
distributed systems etc and there is no _logical_ reason why they
shouldn't have access to csnd, CsoundAC etc. I think of it as we're
bringing csound to python, not the other way around.
Some investigation notes:
According to the code you quote ++, I get ...vers = (2,5) and thus
pvers = 2.5
which resolves to "Python version is 2.5, using MacPython Framework"
from which it sets:
pyBasePath = '/Library/Frameworks/Python.Framework'
which is true for me (my %which python ==> /Library/Frameworks/
Python.framework/Versions/Current/bin/python
however I note from SConstruct:
::::: Checking for C header file /Library/Frameworks/Python.Framework/
Headers/Python.h... (cached) yes ::::
which is true as is
::::: Checking for C header file /Library/Frameworks/Python.framework/
Headers/Python.h... (cached) yes ::::
At first I thought SCons might think these two paths are not
equivalent, but I think it's OK.
Then ...
Checking for SWIG... yes
but "pythonFound = configure.CheckHeader("Python.h", language =
"C")" returns False.
and
::: Checking for C header file Python.h... (cached) no
Just to test, I included '/Library/Frameworks/Python.Framework/
Versions/2.5/include/python2.5/ '
(at which there is a Python.h) in the pythonIncludePath list
but I still get False from "pythonFound =
configure.CheckHeader("Python.h", language = "C")"
So, I don't know why SCons can;t find Python.h, which presumably is
casing SWIG to not build the wrapper.
D.
On 04/04/2008, at 7:29 PM, victor wrote:
> These are the lines of interest for you:
>
> 517 onwards===========================
> elif getPlatform() == 'darwin':
> vers = (int(sys.hexversion) >> 24, (int(sys.hexversion) >> 16) &
> 255)
> if vers[1] == 3:
> print "Python version is 2.%s, using Apple Python Framework" %
> vers[1]
> pyBasePath = '/System/Library/Frameworks/Python.framework'
> else:
> print "Python version is 2.%s, using MacPython Framework" %
> vers[1]
> pyBasePath = '/Library/Frameworks/Python.Framework'
>
>
> I was assuming, and this is prior to 10.5, that Apple's Python is
> 2.3; if
> not we're
> running MacPython. But if Apple's framework is 2.5, then this code
> doesn't
> work.
>
> (I don't have 10.5 here and if I had, then I would not be able to
> produce
> 10.4
> binaries easily (ie. without leaving my office...).) But I suppose I
> will
> have to bite
> the bullet and pay Apple's upgrade tax.
>
> The more I use proprietary software, the more I grow fond of Free.
>
> Victor
>
> ----- Original Message -----
> From: "DavidW" |
| Date | 2008-04-04 13:22 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
yes, that is strange. I would have thought it would
find it. Does it have anything to do with your path
saying '.Framework' instead of '.framework'?
Victor
At 13:07 04/04/2008, you wrote:
>Hi V,
>I'll wait for Felipe then b4 refactoring. Perhaps he can bear in mind
>the issues I've raised.
>I _do_ understand your position on 2.5/2.3 etc and I'm not trying to
>pressure you!
>However I haven't had a csnd system for a while and the pressure of
>work mounts.
>After all, ultimately what we need is a way of being able to build to
>whatever the local conditions are.
>There are very interesting versions of python out there, for
>distributed systems etc and there is no _logical_ reason why they
>shouldn't have access to csnd, CsoundAC etc. I think of it as we're
>bringing csound to python, not the other way around.
>Some investigation notes:
>According to the code you quote ++, I get ...vers = (2,5) and thus
>pvers = 2.5
>which resolves to "Python version is 2.5, using MacPython Framework"
>from which it sets:
> pyBasePath = '/Library/Frameworks/Python.Framework'
>which is true for me (my %which python ==> /Library/Frameworks/
>Python.framework/Versions/Current/bin/python
>however I note from SConstruct:
>::::: Checking for C header file /Library/Frameworks/Python.Framework/
>Headers/Python.h... (cached) yes ::::
>which is true as is
>::::: Checking for C header file /Library/Frameworks/Python.framework/
>Headers/Python.h... (cached) yes ::::
>
>At first I thought SCons might think these two paths are not
>equivalent, but I think it's OK.
>
>Then ...
>Checking for SWIG... yes
>but "pythonFound = configure.CheckHeader("Python.h", language =
>"C")" returns False.
>and
>::: Checking for C header file Python.h... (cached) no
>
>Just to test, I included '/Library/Frameworks/Python.Framework/
>Versions/2.5/include/python2.5/ '
>(at which there is a Python.h) in the pythonIncludePath list
>
>but I still get False from "pythonFound =
>configure.CheckHeader("Python.h", language = "C")"
>
>So, I don't know why SCons can;t find Python.h, which presumably is
>casing SWIG to not build the wrapper.
>
>D.
>
>
>
>On 04/04/2008, at 7:29 PM, victor wrote:
> > These are the lines of interest for you:
> >
> > 517 onwards===========================
> > elif getPlatform() == 'darwin':
> > vers = (int(sys.hexversion) >> 24, (int(sys.hexversion) >> 16) &
> > 255)
> > if vers[1] == 3:
> > print "Python version is 2.%s, using Apple Python Framework" %
> > vers[1]
> > pyBasePath = '/System/Library/Frameworks/Python.framework'
> > else:
> > print "Python version is 2.%s, using MacPython Framework" %
> > vers[1]
> > pyBasePath = '/Library/Frameworks/Python.Framework'
> >
> >
> > I was assuming, and this is prior to 10.5, that Apple's Python is
> > 2.3; if
> > not we're
> > running MacPython. But if Apple's framework is 2.5, then this code
> > doesn't
> > work.
> >
> > (I don't have 10.5 here and if I had, then I would not be able to
> > produce
> > 10.4
> > binaries easily (ie. without leaving my office...).) But I suppose I
> > will
> > have to bite
> > the bullet and pay Apple's upgrade tax.
> >
> > The more I use proprietary software, the more I grow fond of Free.
> >
> > Victor
> >
> > ----- Original Message -----
> > From: "DavidW" |
| Date | 2008-04-04 13:34 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
On 04/04/2008, at 11:22 PM, Victor Lazzarini wrote:
> yes, that is strange. I would have thought it would
> find it. Does it have anything to do with your path
> saying '.Framework' instead of '.framework'?
>
> Victor
>
I did checked that - by substitution - but it didn't make any
difference.
It looks like configure.CheckHeader is having problems. Perhaps I'll
have a browse of the SCons manual for clues.
D.
> At 13:07 04/04/2008, you wrote:
>> Hi V,
>> I'll wait for Felipe then b4 refactoring. Perhaps he can bear in mind
>> the issues I've raised.
>> I _do_ understand your position on 2.5/2.3 etc and I'm not trying to
>> pressure you!
>> However I haven't had a csnd system for a while and the pressure of
>> work mounts.
>> After all, ultimately what we need is a way of being able to build to
>> whatever the local conditions are.
>> There are very interesting versions of python out there, for
>> distributed systems etc and there is no _logical_ reason why they
>> shouldn't have access to csnd, CsoundAC etc. I think of it as we're
>> bringing csound to python, not the other way around.
>> Some investigation notes:
>> According to the code you quote ++, I get ...vers = (2,5) and thus
>> pvers = 2.5
>> which resolves to "Python version is 2.5, using MacPython Framework"
>> from which it sets:
>> pyBasePath = '/Library/Frameworks/Python.Framework'
>> which is true for me (my %which python ==> /Library/Frameworks/
>> Python.framework/Versions/Current/bin/python
>> however I note from SConstruct:
>> ::::: Checking for C header file /Library/Frameworks/
>> Python.Framework/
>> Headers/Python.h... (cached) yes ::::
>> which is true as is
>> ::::: Checking for C header file /Library/Frameworks/
>> Python.framework/
>> Headers/Python.h... (cached) yes ::::
>>
>> At first I thought SCons might think these two paths are not
>> equivalent, but I think it's OK.
>>
>> Then ...
>> Checking for SWIG... yes
>> but "pythonFound = configure.CheckHeader("Python.h", language =
>> "C")" returns False.
>> and
>> ::: Checking for C header file Python.h... (cached) no
>>
>> Just to test, I included '/Library/Frameworks/Python.Framework/
>> Versions/2.5/include/python2.5/ '
>> (at which there is a Python.h) in the pythonIncludePath list
>>
>> but I still get False from "pythonFound =
>> configure.CheckHeader("Python.h", language = "C")"
>>
>> So, I don't know why SCons can;t find Python.h, which presumably is
>> casing SWIG to not build the wrapper.
>>
>> D.
>>
>>
>>
>> On 04/04/2008, at 7:29 PM, victor wrote:
>>> These are the lines of interest for you:
>>>
>>> 517 onwards===========================
>>> elif getPlatform() == 'darwin':
>>> vers = (int(sys.hexversion) >> 24, (int(sys.hexversion) >> 16) &
>>> 255)
>>> if vers[1] == 3:
>>> print "Python version is 2.%s, using Apple Python Framework" %
>>> vers[1]
>>> pyBasePath = '/System/Library/Frameworks/Python.framework'
>>> else:
>>> print "Python version is 2.%s, using MacPython Framework" %
>>> vers[1]
>>> pyBasePath = '/Library/Frameworks/Python.Framework'
>>>
>>>
>>> I was assuming, and this is prior to 10.5, that Apple's Python is
>>> 2.3; if
>>> not we're
>>> running MacPython. But if Apple's framework is 2.5, then this code
>>> doesn't
>>> work.
>>>
>>> (I don't have 10.5 here and if I had, then I would not be able to
>>> produce
>>> 10.4
>>> binaries easily (ie. without leaving my office...).) But I suppose I
>>> will
>>> have to bite
>>> the bullet and pay Apple's upgrade tax.
>>>
>>> The more I use proprietary software, the more I grow fond of Free.
>>>
>>> Victor
>>>
>>> ----- Original Message -----
>>> From: "DavidW" |
| Date | 2008-04-04 13:48 |
| From | Victor Lazzarini |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
One quick suggestion:
sudo ln -sf
/Library/Frameworks/Python.Framework/Versions/2.5/include/python2.5/Python.h
/usr/include/python2.5/Python.h
Might help.
Also scons reports first that it can't find Python.h, but then it looks in the
right place. This is what I get here...
Checking for SWIG... yes
Checking for C header file Python.h... no
Checking for C header file
/System/Library/Frameworks/Python.framework/Headers/Python.h... yes
Victor
At 13:34 04/04/2008, you wrote:
>On 04/04/2008, at 11:22 PM, Victor Lazzarini wrote:
> > yes, that is strange. I would have thought it would
> > find it. Does it have anything to do with your path
> > saying '.Framework' instead of '.framework'?
> >
> > Victor
> >
>I did checked that - by substitution - but it didn't make any
>difference.
>It looks like configure.CheckHeader is having problems. Perhaps I'll
>have a browse of the SCons manual for clues.
>
>D.
> > At 13:07 04/04/2008, you wrote:
> >> Hi V,
> >> I'll wait for Felipe then b4 refactoring. Perhaps he can bear in mind
> >> the issues I've raised.
> >> I _do_ understand your position on 2.5/2.3 etc and I'm not trying to
> >> pressure you!
> >> However I haven't had a csnd system for a while and the pressure of
> >> work mounts.
> >> After all, ultimately what we need is a way of being able to build to
> >> whatever the local conditions are.
> >> There are very interesting versions of python out there, for
> >> distributed systems etc and there is no _logical_ reason why they
> >> shouldn't have access to csnd, CsoundAC etc. I think of it as we're
> >> bringing csound to python, not the other way around.
> >> Some investigation notes:
> >> According to the code you quote ++, I get ...vers = (2,5) and thus
> >> pvers = 2.5
> >> which resolves to "Python version is 2.5, using MacPython Framework"
> >> from which it sets:
> >> pyBasePath = '/Library/Frameworks/Python.Framework'
> >> which is true for me (my %which python ==> /Library/Frameworks/
> >> Python.framework/Versions/Current/bin/python
> >> however I note from SConstruct:
> >> ::::: Checking for C header file /Library/Frameworks/
> >> Python.Framework/
> >> Headers/Python.h... (cached) yes ::::
> >> which is true as is
> >> ::::: Checking for C header file /Library/Frameworks/
> >> Python.framework/
> >> Headers/Python.h... (cached) yes ::::
> >>
> >> At first I thought SCons might think these two paths are not
> >> equivalent, but I think it's OK.
> >>
> >> Then ...
> >> Checking for SWIG... yes
> >> but "pythonFound = configure.CheckHeader("Python.h", language =
> >> "C")" returns False.
> >> and
> >> ::: Checking for C header file Python.h... (cached) no
> >>
> >> Just to test, I included '/Library/Frameworks/Python.Framework/
> >> Versions/2.5/include/python2.5/ '
> >> (at which there is a Python.h) in the pythonIncludePath list
> >>
> >> but I still get False from "pythonFound =
> >> configure.CheckHeader("Python.h", language = "C")"
> >>
> >> So, I don't know why SCons can;t find Python.h, which presumably is
> >> casing SWIG to not build the wrapper.
> >>
> >> D.
> >>
> >>
> >>
> >> On 04/04/2008, at 7:29 PM, victor wrote:
> >>> These are the lines of interest for you:
> >>>
> >>> 517 onwards===========================
> >>> elif getPlatform() == 'darwin':
> >>> vers = (int(sys.hexversion) >> 24, (int(sys.hexversion) >> 16) &
> >>> 255)
> >>> if vers[1] == 3:
> >>> print "Python version is 2.%s, using Apple Python Framework" %
> >>> vers[1]
> >>> pyBasePath = '/System/Library/Frameworks/Python.framework'
> >>> else:
> >>> print "Python version is 2.%s, using MacPython Framework" %
> >>> vers[1]
> >>> pyBasePath = '/Library/Frameworks/Python.Framework'
> >>>
> >>>
> >>> I was assuming, and this is prior to 10.5, that Apple's Python is
> >>> 2.3; if
> >>> not we're
> >>> running MacPython. But if Apple's framework is 2.5, then this code
> >>> doesn't
> >>> work.
> >>>
> >>> (I don't have 10.5 here and if I had, then I would not be able to
> >>> produce
> >>> 10.4
> >>> binaries easily (ie. without leaving my office...).) But I suppose I
> >>> will
> >>> have to bite
> >>> the bullet and pay Apple's upgrade tax.
> >>>
> >>> The more I use proprietary software, the more I grow fond of Free.
> >>>
> >>> Victor
> >>>
> >>> ----- Original Message -----
> >>> From: "DavidW" |
| Date | 2008-04-04 17:34 |
| From | Felipe Sateler |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | None None None |
| Date | 2008-04-05 13:09 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
On 04/04/2008, at 11:48 PM, Victor Lazzarini wrote: > One quick suggestion: > > sudo ln -sf > /Library/Frameworks/Python.Framework/Versions/2.5/include/python2.5/ > Python.h > /usr/include/python2.5/Python.h > > Might help. > unfortunately not. > Also scons reports first that it can't find Python.h, but then it > looks in the > right place. This is what I get here... > > Checking for SWIG... yes > Checking for C header file Python.h... no > Checking for C header file > /System/Library/Frameworks/Python.framework/Headers/Python.h... yes > > Victor > >>>>> same for me. I also tried under scons 0.98 w. the same result. And I tried this http://www.scons.org/doc/0.98.0/HTML/scons-user/x2985.html but to no effect. I read here: http://www.scons.org/doc/0.98.0/HTML/scons-user/x2985.html > Note that SCons uses its own dependency mechanism to determine when > a check needs to be run--that is, SCons does not run the checks > every time it is invoked, but caches the values returned by previous > checks and uses the cached values unless something has changed. This > saves a tremendous amount of developer time while working on cross- > platform build issues. > I couldn't find a cache, but in case I'd missed it, I tried: sudo scons --cache-disable dynamicCsoundLibrary=1 buildCsoundAC=1 to no effect. grrrr D. ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net |
| Date | 2008-04-06 13:48 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | SConstruct2.py None None |
Hi Felipe, Attached is some work on SConstruct2 The file is named Construct2.py because I've been working on it in a keyword-aware editor. I've gone for making the logical flow clearer by getting as much on a screen as possible. This means making the lines longer - actually there were all sorts of length 'standards' so All I've done is adopt the longest one. I hope you agree it's more readable. We can always shorten them later if anyone objects. There is an error around line 966 ++ which I've clearly marked. It looks like you hadn't finished implementing an idea, so I've left the logic as you had. And noted where I think the problem is. We can do some more factoring later. For eg I was wondering about a set of classes, one for each platform, which inherit from a generic one. If you're happy with this, you could take out the lines with #drw' on them, drop the .py off the end and submit is to the repository. (I don't have write access.) regards, David On 05/04/2008, at 3:34 AM, Felipe Sateler wrote: > On Friday 04 April 2008 08:07:35 DavidW wrote: >> I'll wait for Felipe then b4 refactoring. Perhaps he can bear in mind >> the issues I've raised. > > You're welcome to make these modifications on the SConstruct2 file > (and in any > SConscripts that will appear over time). I'm a little short on time > now, so > it'll take some time before I finish the refactoring. > There are certainly some strange things going on, so if you manage to > eliminate some of those, it'll make my work easier too. > |
| Date | 2008-04-06 17:46 |
| From | Felipe Sateler |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | None None None |
| Date | 2008-04-06 22:15 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | SConstruct2_80.py None None |
The 80char/line rule made sense when variable names couldn' t be over
a few chars and OOP didn't allow
aVeryLongBaseName.anEvenLongerMethodName('a string which is even
longer and is hard to break.')
type practice. Anyway I'm not interested in banging on about that
(I'll leave the banging in MAX users)
Readability is very important and lack of it causes bugs.
I do not think it coincidental, for eg. that the very section with the
error in it is where 'tab' had gotten down to 2 chars.
Attached is an (almost) 80char/line clean version. I've left a ruler
in where there's an overrun of more than a couple of chars.
I hope it's of some use. Two ways to reduce the number of these would be
1. factor often used char strings, such as "CONFIGURATION DECISION: "
to something smaller and add, as appropriate
2. Abbreviate some of the Method names (Eg use Environ or Ement for
Environment)
ciao,
David
On 07/04/2008, at 2:46 AM, Felipe Sateler wrote:
> Thanks for your work. However, there are a couple of issues. I don't
> know
> about the rest here, but I normally try to not exceed 80 columns in
> a text
> file, because it makes editing on a terminal easier (I tend to use
> vim, so
> this is important for me). For example, some of your changes change
> lines of
> the form
>
> if someReallyLongTest:
> doSomething()
>
> into
>
> if someReallyLongTest: doSomething()
>
> Which runs far over the 80-column limit several times.
> Also I'm not really sure your formatting adds to readability (I
> think it
> actually makes it more difficult: it mixes the casing and the actual
> code).
>
> I like the platform thing, though. I'll implement this for now, and
> fix the
> error you found in the static library part, but I'm afraid I can't
> just
> include your changes, because of the formatting problem.
>
|
| Date | 2008-04-06 22:30 |
| From | Felipe Sateler |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | None None None |
| Date | 2008-04-06 22:53 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
Same version as yesterday. Having spent 3 hours on it and you said you
wouldn't use it I just spent another 1/2 hour reformatted it according
to the 80 char /line rule, despite the file not conforming to that
rule in many other places from the beginning.
Anyway, do what you want with it. I'm not going to chase reformatting
a badly formatted file.
D.
On 07/04/2008, at 7:30 AM, Felipe Sateler wrote:
> On Sunday 06 April 2008 17:15:15 DavidW wrote:
>> The 80char/line rule made sense when variable names couldn' t be over
>> a few chars and OOP didn't allow
>> aVeryLongBaseName.anEvenLongerMethodName('a string which is even
>> longer and is hard to break.')
>> type practice. Anyway I'm not interested in banging on about that
>> (I'll leave the banging in MAX users)
>> Readability is very important and lack of it causes bugs.
>> I do not think it coincidental, for eg. that the very section with
>> the
>> error in it is where 'tab' had gotten down to 2 chars.
>>
>> Attached is an (almost) 80char/line clean version. I've left a ruler
>> in where there's an overrun of more than a couple of chars.
>
> You seem to have used another version? This file still uses
> util.getPlatform
> instead of util.platform.
>
>> I hope it's of some use. Two ways to reduce the number of these
>> would be
>> 1. factor often used char strings, such as "CONFIGURATION DECISION: "
>> to something smaller and add, as appropriate
>
> There's already some of this, although it's not implemented
> everywhere: see
> util.confDecision and util.fatal.
>
>> 2. Abbreviate some of the Method names (Eg use Environ or Ement for
>> Environment)
>
> 3. Break lines at function arguments and other places, eg
> someClass.someFunction(oneArgument,
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |
| Date | 2008-04-07 01:19 |
| From | Felipe Sateler |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | None None None |
| Date | 2008-04-07 03:29 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
On 07/04/2008, at 10:19 AM, Felipe Sateler wrote:
> On Sunday 06 April 2008 17:53:38 DavidW wrote:
>> Same version as yesterday.
>
> Oh, my bad. There are a couple of getPlatform calls, and I thought
> that all
> calls were not replaced.
>
I think your Utility.__init__() is superior. Perhaps it would be good
to use it to set the default command options etc. this way.
> I applied most of the changes you made. Left out are some
> conversions that
> didn't seem consistent, such as
>
> if a:
> doSomething()
> doSomethingElse()
> if b: doAnotherThing()
>
Yeh, there are some inconsistencies, as you mention. I thought you
said you weren't going to be working on it for a while so I didn't l
expect it to change so quickly. When you did, I wanted to update as
quickly as possible.
---
Do you think I should get checkin status? - it would fix this problem.
If so, how?
----
insert at line 237
commandOptions.Add('useFLTK',
'Set to 1 to use FLTK for graphs and widget opcodes.',
'1')
(and other appropriate env if necess)
Its causing
commandOptions.Add('useFLTK', 'Set to 1 to use FLTK for graphs and
widget opcodes.', '1')
to exception ~ 10 lines from EOF.
> Thanks for your time and effort.
>
no worries. all towards a better Env().
D.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |
| Date | 2008-04-07 04:06 |
| From | Felipe Sateler |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | None None None |
| Date | 2008-04-07 04:27 |
| From | DavidW |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
On 07/04/2008, at 1:06 PM, Felipe Sateler wrote:
>> ----
>> insert at line 237
>> commandOptions.Add('useFLTK',
>> 'Set to 1 to use FLTK for graphs and widget opcodes.',
>> '1')
>> (and other appropriate env if necess)
>>
>> Its causing
>> commandOptions.Add('useFLTK', 'Set to 1 to use FLTK for graphs and
>> widget opcodes.', '1')
>> to exception ~ 10 lines from EOF.
>
> I don't understand this. It may be that you mail client broke the
> formatting,
> but single quoted strings can't be split into multiple lines.
>
sorry - that's the list mailer doing the line breaks.
My point is that
>> commandOptions.Add('useFLTK',
>> 'Set to 1 to use FLTK for graphs and widget opcodes.',
>> '1')
need to be inserted (IT USED TO BE at line 237 or thereabouts)
for the EOF minus 10 lines command:
if util.platform == 'darwin' and commonEnvironment['useFLTK'] == '1':
print "CONFIGURATION DECISION: Adding resource fork for csound"
util.addOSXResourceFork(commonEnvironment, 'csound', '')
not to exception. In was missing in today's CVS update.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Register now and save $200. Hurry, offer ends at 11:59 p.m.,
Monday, April 7! Use priority code J8TLD2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |
| Date | 2008-04-07 04:58 |
| From | Felipe Sateler |
| Subject | Re: [Cs-dev] CSonstruct cosmetic surgery : (was Re: SConstruct fixed(was...)) |
| Attachments | None None None |