> Let me assume you're not purposely misrepresenting my point....  I am  not 
> arguing for some unspecified version of "SWIG to make a non- 
> version-specific wrapper":
> - A User with machine X with OS version Y and Python version Z and  wants 
> to build csound for it.
> - The User installs the version of SWIG etc appropriate for their X, Y 
> and Z.
> - The User downloads the csound sources and runs the SConstruct.
> - If it doesn't build/install etc appropriate to The User's machine,  then 
> it is a csound problem, unless it originates as a "specific  version of 
> SWIG problem." Even then, it is a csound problem because,  given 
> people-power, communication with SWIG dev. team etc, it it  likely to be 
> solvable.

It is not appropriate for SCons
to try to deduce the version of Python to use, precisely because users may 
have
more than one version of Python installed on their computer. There is a 
Python version argument for SCons,
and you can set specific PATH variables in your environment and other
paths in your custom.py to match that version.

> I know about frameworks and different versions of python, as I've said 
> before. And I've probably been using PATH variables longer than many  on 
> this list have been alive. But this doesn't solve the problem, as  I've 
> said before. If  A, B, C etc need to be done as part of a  composition 
> process and all the tools to do that except csound build  to install for 
> (one reasonable/the latest version of) python, how does  having different 
> versions available solve the problem? I do not accept  the argument that 
> it is good practice for the whole world to revolve  around a particular 
> version of python just because of csound. If the  world marches to a 
> particular step and csound is not instep, then it  is csound, not the 
> world. that is out-of-step.
>
>> It also, of course, is possible to simply throw out annoying parts  of 
>> Csound, as Art Hunkins has so clearly explained.
>>
> As a user?

That's what Art Hunkins did, isn't it?

>> In the meantime, be assured that I will make every reasonable effort  to 
>> make the installer, and Csound, easier to use. More information  about 
>> specific problems, including OS and Csound and Python  versions, and 
>> screen shots of error messages, would be most useful.
>>
> Thanks.

You're welcome.

>> I am considering creating two installers, one with a "cut-down"  release 
>> of Csound, and one with all bells and whistles including all  the 
>> language APIs. Then the installer with Python stuff wouldn't  have to try 
>> to figure out what is what on the installee's computer.
>>
>> I also will look into changing the build system to use Python  distutils 
>> to make the Python extension module, although I am not  sure that this 
>> will really be an improvement.
>>
> Lets discuss the options.

Are you more concerned about building Csound, or about installing it?

Regards,
Mike

On 03/07/2009, at 12:14 PM, michael.gogins@gmail.com wrote:
> It is not appropriate for SCons
> to try to deduce the version of Python to use, precisely because  
> users may have
> more than one version of Python installed on their computer. There  
> is a Python version argument for SCons,
> and you can set specific PATH variables in your environment and other
> paths in your custom.py to match that version.
>
There is a python version argument for python so it must be there for  
SCons:
 >>> import sys; sys.executable
'/Library/Frameworks/Python.framework/Versions/2.5/Resources/ 
Python.app/Contents/MacOS/Python'

Each version of python has its own SCons, doesn't it? It does for me  
on OSX:
$ which python
/Library/Frameworks/Python.framework/Versions/Current/bin/python
$ which scons
/Library/Frameworks/Python.framework/Versions/Current/bin/scons

So if I wanted to compile csound for a particular installed version of  
python I would just reassign Current to that one, as per usual.

>> I know about frameworks and different versions of python, as I've  
>> said before. And I've probably been using PATH variables longer  
>> than many  on this list have been alive. But this doesn't solve the  
>> problem, as  I've said before. If  A, B, C etc need to be done as  
>> part of a  composition process and all the tools to do that except  
>> csound build  to install for (one reasonable/the latest version of)  
>> python, how does  having different versions available solve the  
>> problem? I do not accept  the argument that it is good practice for  
>> the whole world to revolve  around a particular version of python  
>> just because of csound. If the  world marches to a particular step  
>> and csound is not instep, then it  is csound, not the world. that  
>> is out-of-step.
>>
>>> It also, of course, is possible to simply throw out annoying  
>>> parts  of Csound, as Art Hunkins has so clearly explained.
>>>
>> As a user?
>
> That's what Art Hunkins did, isn't it?
I don't  know - I thought he was on OLPC so I didn't read in detail.  
In any event, "throwing out the annoying parts" implies that a user  
knows how to do that; implies a quite advanced knowledge of csound  
which it would not reasonable to expect of many users.
>
>>> In the meantime, be assured that I will make every reasonable  
>>> effort  to make the installer, and Csound, easier to use. More  
>>> information  about specific problems, including OS and Csound and  
>>> Python  versions, and screen shots of error messages, would be  
>>> most useful.
>>>
>> Thanks.
>
> You're welcome.
but see the error part of my post of today ([Csnd] more improvements:  
manual+errors)

>>> I am considering creating two installers, one with a "cut-down"   
>>> release of Csound, and one with all bells and whistles including  
>>> all  the language APIs. Then the installer with Python stuff  
>>> wouldn't  have to try to figure out what is what on the  
>>> installee's computer.
>>>
>>> I also will look into changing the build system to use Python   
>>> distutils to make the Python extension module, although I am not   
>>> sure that this will really be an improvement.
>>>
>> Lets discuss the options.
>
> Are you more concerned about building Csound, or about installing it?
>
I am more concerned with installing than building.
However, in the absence of an existing build that works for my setup  
I'm prepared to build, as I frequently do with lots of other stuff.
My argument is that, at least wrt the API, the ideal situation is that  
there should be very little difference, given the right tools and an  
environment-sensitive build script.


________________________________________________
David Worrall.
- Experimental Polymedia:	  worrall.avatar.com.au
- Sonification: www.sonifiction.com.au
- Education for Financial Independence: www.mindthemarkets.com.au

The SConscript does guess the currently running python version(because
scons is run by python), and tries to find appropriate paths for it.
At least on linux.

On 07/07/2009, DavidW  wrote:
>
> On 03/07/2009, at 12:14 PM, michael.gogins@gmail.com wrote:
> > It is not appropriate for SCons
> > to try to deduce the version of Python to use, precisely because users may
> have
> > more than one version of Python installed on their computer. There is a
> Python version argument for SCons,
> > and you can set specific PATH variables in your environment and other
> > paths in your custom.py to match that version.
> >
> >
> There is a python version argument for python so it must be there for SCons:
> >>> import sys; sys.executable
> '/Library/Frameworks/Python.framework/Versions/2.5/Resources/Python.app/Contents/MacOS/Python'
>
> Each version of python has its own SCons, doesn't it? It does for me on OSX:
> $ which python
> /Library/Frameworks/Python.framework/Versions/Current/bin/python
> $ which scons
> /Library/Frameworks/Python.framework/Versions/Current/bin/scons
>
> So if I wanted to compile csound for a particular installed version of
> python I would just reassign Current to that one, as per usual.
>
> >
> > > I know about frameworks and different versions of python, as I've said
> before. And I've probably been using PATH variables longer than many  on
> this list have been alive. But this doesn't solve the problem, as  I've said
> before. If  A, B, C etc need to be done as part of a  composition process
> and all the tools to do that except csound build  to install for (one
> reasonable/the latest version of) python, how does  having different
> versions available solve the problem? I do not accept  the argument that it
> is good practice for the whole world to revolve  around a particular version
> of python just because of csound. If the  world marches to a particular step
> and csound is not instep, then it  is csound, not the world. that is
> out-of-step.
> > >
> > >
> > > > It also, of course, is possible to simply throw out annoying parts  of
> Csound, as Art Hunkins has so clearly explained.
> > > >
> > > >
> > > As a user?
> > >
> >
> > That's what Art Hunkins did, isn't it?
> >
> I don't  know - I thought he was on OLPC so I didn't read in detail. In any
> event, "throwing out the annoying parts" implies that a user knows how to do
> that; implies a quite advanced knowledge of csound which it would not
> reasonable to expect of many users.
> >
> >
> > >
> > > > In the meantime, be assured that I will make every reasonable effort
> to make the installer, and Csound, easier to use. More information  about
> specific problems, including OS and Csound and Python  versions, and screen
> shots of error messages, would be most useful.
> > > >
> > > >
> > > Thanks.
> > >
> >
> > You're welcome.
> >
> but see the error part of my post of today ([Csnd] more improvements:
> manual+errors)
>
> >
> > >
> > > > I am considering creating two installers, one with a "cut-down"
> release of Csound, and one with all bells and whistles including all  the
> language APIs. Then the installer with Python stuff wouldn't  have to try to
> figure out what is what on the installee's computer.
> > > >
> > > > I also will look into changing the build system to use Python
> distutils to make the Python extension module, although I am not  sure that
> this will really be an improvement.
> > > >
> > > >
> > > Lets discuss the options.
> > >
> >
> > Are you more concerned about building Csound, or about installing it?
> >
> >
> I am more concerned with installing than building.
> However, in the absence of an existing build that works for my setup I'm
> prepared to build, as I frequently do with lots of other stuff.
> My argument is that, at least wrt the API, the ideal situation is that there
> should be very little difference, given the right tools and an
> environment-sensitive build script.
>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:         worrall.avatar.com.au
> - Sonification: www.sonifiction.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
>
>
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>


-- 

Saludos,
Felipe Sateler