I think we need to see how this shakes out. Anything as complex as Csound now is, needs to be simplified as much as possible, so I would prefer a single library. 

If there are platforms or users who have problems building a single library with the wrappers then of course it should be possible to configure the build to exclude the wrappers. But unless there is some compelling reason to the contrary I think the wrappers should be built by default in the main library. This is so that users of Csound will be presented with a consistent, easy to use toolkit and people will not make false assumptions about what is and what is not possible with Csound.

Regards,
Mike



-----Original Message-----
From: Istvan Varga 
Sent: Oct 13, 2005 5:11 AM
To: csound@lists.bath.ac.uk
Subject: Re: [Csnd] Common Music and Csound 5

Michael Gogins wrote:

> I believe Csound is a sound synthesis language that can be run
 > either standalone or embedded in other applications, with bindings
 > for all languages that are widely used for algorithmic composition,
 > so that it can be embedded in composing software. I have been using
 > Csound this way for almost 10 years. I can testify that the embedding
 > provides a substantial increase in production efficiency.

Well, of course the wrappers can be useful, and I did not mean they
should not exist. However, I think it should be possible to build a
basic library with as few dependencies as possible, with only the
standard C API, and have the wrappers either as a separate library
that links against libcsound - as it already is, or make them optional.
-- 
Send bugs reports to this list.
To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk

> This is so that users of Csound will be presented with a consistent, easy to
> use toolkit and people will not make false assumptions about what is and what
> is not possible with Csound.

Well, I think this is an interesting point.  Witness all of the confusion we
have seen here recently over FLTK.  Most Linux people already have FLTK
installed, and Windows and MacOS X users can download precompiled binaries.
But no one seems to end up with an -enable-threads'ed library by default, to
no end of confusion when trying to compile Csound.

I can certainly imagine a similar situation happening if some of the more
"popular" ways to obtain a binary libcsound release do not include
functionality such as the Python wrapper, but many people are trying to
install some nice new Python GUI over top of the library.

But, as a developer, I previously stated as well that I would like the
wrappers to be optional.  *shrug*

> If there are platforms or users who have problems building a single library
> with the wrappers then of course it should be possible to configure the build
> to exclude the wrappers. But unless there is some compelling reason to the
> contrary I think the wrappers should be built by default in the main library.

Here is a question for you, Mike.  You stated that there would be no
additional dependencies besides SWIG, but that the SWIG output could be
checked into CVS, thus alleviating that dependency (at least for anyone not
changing the API).  But, you must be at least assuming a C++ compiler (which
I don't think would be a problem for any _desktop_ platform), and I also am
guessing that you are assuming the presence of Python.  (Which at first
seems reasonable because of Scons).

But, will the Python dev package also have to be installed (the headers) in
order to make a wrapper?  And let's keep in mind that there are some people
building (or attempting to build) Csound without Scons.  (Myself included!
Scons doesn't work on MacOS 9, so I have a CodeWarrior IDE project set up
for the build).

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://akozar.spymac.net/

Anthony Kozar wrote:

>>This is so that users of Csound will be presented with a consistent, easy to
>>use toolkit and people will not make false assumptions about what is and what
>>is not possible with Csound.
> 
> I can certainly imagine a similar situation happening if some of the more
> "popular" ways to obtain a binary libcsound release do not include
> functionality such as the Python wrapper, but many people are trying to
> install some nice new Python GUI over top of the library.
> 
> But, as a developer, I previously stated as well that I would like the
> wrappers to be optional.  *shrug*

So, by keeping the wrappers in a separate library, there is no confusion
about the main library containing them or not, yet it is possible to build
a version of libcsound that is smaller, more portable, and has less
dependencies.

Why not have two mirrored releases available, one that is by default 
very minimal, and the other by default includes everything? I know as a 
relatively novice programmer, that is what I would prefer on the 
receiving end.

Iain

Anthony Kozar wrote:
>>This is so that users of Csound will be presented with a consistent, easy to
>>use toolkit and people will not make false assumptions about what is and what
>>is not possible with Csound.
> 
> 
> Well, I think this is an interesting point.  Witness all of the confusion we
> have seen here recently over FLTK.  Most Linux people already have FLTK
> installed, and Windows and MacOS X users can download precompiled binaries.
> But no one seems to end up with an -enable-threads'ed library by default, to
> no end of confusion when trying to compile Csound.
> 
> I can certainly imagine a similar situation happening if some of the more
> "popular" ways to obtain a binary libcsound release do not include
> functionality such as the Python wrapper, but many people are trying to
> install some nice new Python GUI over top of the library.
> 
> But, as a developer, I previously stated as well that I would like the
> wrappers to be optional.  *shrug*
> 
> 
>>If there are platforms or users who have problems building a single library
>>with the wrappers then of course it should be possible to configure the build
>>to exclude the wrappers. But unless there is some compelling reason to the
>>contrary I think the wrappers should be built by default in the main library.
> 
> 
> Here is a question for you, Mike.  You stated that there would be no
> additional dependencies besides SWIG, but that the SWIG output could be
> checked into CVS, thus alleviating that dependency (at least for anyone not
> changing the API).  But, you must be at least assuming a C++ compiler (which
> I don't think would be a problem for any _desktop_ platform), and I also am
> guessing that you are assuming the presence of Python.  (Which at first
> seems reasonable because of Scons).
> 
> But, will the Python dev package also have to be installed (the headers) in
> order to make a wrapper?  And let's keep in mind that there are some people
> building (or attempting to build) Csound without Scons.  (Myself included!
> Scons doesn't work on MacOS 9, so I have a CodeWarrior IDE project set up
> for the build).
> 
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> http://akozar.spymac.net/
> 

Iain Duncan wrote:

> Why not have two mirrored releases available, one that is by default 
> very minimal, and the other by default includes everything? I know as a 
> relatively novice programmer, that is what I would prefer on the 
> receiving end.

Again, this can be solved by having the wrappers in a separate
library.