Thanks for your thoughts. Here's my response.

I used to have a configure.in, Makefile.am, autoconf, automake, libtool
build system for Csound 4. I only used it on Linux and I dropped it because
I needed to focus on SourceForge Csound. (Working on 2 builds for Csound
was a real nightmare, especially because I would get stuff working in my
build that was not adopted, or not quickly adopted, by the "canonical"
build. Getting Csound under LGPL and into SourceForge CVS has been a
GOD-SEND for me!) 

I have been encouraging Csound developers to move in this GNU direction. I
think it was a mistake not to use automake for Csound 4 and 5, and I think
it should be used.

Csound has to build on many platforms. Autoconf doesn't handle audio
libraries well, especially on Windows. We could deal with that using custom
build rules in the Makefile.am's. 

I would like to focus on Csound 5. I'd like to see a standard GNU build
system for Csound 5 driven by configure.ac and Makefile.am's, using
autoconf, automake, and libtool, that will work on Linux, Unix, Windows,
and Mac OS X.

The dynamic loading of plugins is also problematic, but perhaps it could be
done by incorporating libtdl. Howevever, if libtdl doesn't work or is
difficult on Windows, then I suggest my original plan (the functions we
have been discussing).

Csound also has numerous contributors. Most don't understand the GNU build
system, so it would be nice to provide step by step instructions for
building from sources, adding new c files, and making plugin opcodes. Such
documentation should be part of the regular Csound manual.


Original Message:
-----------------
From:  ramsdell@mitre.org (John D. Ramsdell)
Date: 05 Nov 2003 07:06:57 -0500
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3284] Re: ccsound.c


Michael,

I have yet to spend any time thinking about or contributing code to
better support plugins.  The only thing I did was provide a compile
time switch that can be used to produce libraries that stub out
undefined references that are created when you try to link in
applications that only define csoundMessage0.  The LOSE_LOAD_LIBRARIES
was added only because I wanted to make the system work with wxCSound,
and did not express an opinion as to whether your interface to dynamic
linking is better or worse that John's.  Steven seems to be more in
tune with the issues.

Having said all that, however, it appears to me all of you are trying
to solve a problem that libtool was designed to address.  It is hard
for me to believe that members of this team can do better job than
what results from the collective effort of developers and users of
libtool.

I do *not* think libtool usage by the Csound project should be
investigated at this time.  It is far easier to employ libtool in a
project that uses automake to create its Makefile.in's.  I'll study
all the existing Makefile.in's in the csound5 module, and report on
the feasibility of generating the Makefile.in's using automake
sometime soon.  My agenda is to make "make install" behave as most
people expect.  My RPM spec file requires standard behavior.  This
agenda explains why I want the top-level Makefile to end up with
definitions for things like $(pkgdatadir) and the like.

> ... By the way, do you make a Mac OSX build of wxCsound?

The only binaries I distribute are for Windows.  Ironically, this is
the only platform on which it has severe memory errors.  I suppose I
should try to build it using Microsoft's build environment, but I'm
loath to install their stuff on my Window 2000 laptop.  Last time I
did that, I ended filling the disk, and one thing led to any other,
and before I knew it, I had to format the disk and reload the
operating system.

In any event, you should be able to easily build wxCSound from its
sources on the Mac.  It's just the usual ./configure followed by make
routine.

I just noticed that I've been writing CSound in various places, and
everyone else writes Csound.  I promise to get with the program, and
rename wxCSound to wxCsound.  Silly me...

John


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

"gogins@pipeline.com"  writes:

> Thanks for your thoughts. Here's my response.
> 
> I used to have a configure.in, Makefile.am, autoconf, automake,
> libtool build system for Csound 4. I only used it on Linux and I
> dropped it because I needed to focus on SourceForge Csound. (Working
> on 2 builds for Csound was a real nightmare, especially because I
> would get stuff working in my build that was not adopted, or not
> quickly adopted, by the "canonical" build. Getting Csound under LGPL
> and into SourceForge CVS has been a GOD-SEND for me!)

Well gee, it sounds to me as if Michael has already solved our
configuration problems.  All others, is there any reason we shouldn't
let Michael do his magic on the csound5 module?  I say we step aside
and let him go!

John