I have a new build system based on a single Makefile.am that now succeeds in
building the Csound API library, the Csound console executable linked with
the the API library, all the plugin opcodes, and all the utilities on Cygwin
(using the Cygwin dll). The system links with the FLTK GUI and windows,
PortAudio, Windows MIDI, and libsndfile.

I have not tested any utilities. All plugin opcodes seem to load, and I can
render a short part of the beginning of Trapped in Convert before crashing.

Changes are summarized below. There are so many changes that
the standalone Makefile.in file doesn't work any more.

Before committing any files, I would like to know what John Fitch and
others would prefer. The options are:

1. I can simply commit my changes, and Csound developers will need to adapt
to the new Makefile.am system, and fix any problems that remain or that it
created.
If desired, the standalone Makefile.in could be resurrected by using the new
ustub library the
same way that the new Makefile.am does.

2. I can branch the Csound 5 package, and development of Csound 5 with the
Makefile.am system can continue in the new branch.

I prefer the first option because the whole motivation for the new build
system is to simplify building, maintaining, and extending Csound. With the
new system,
adding new targets or files to Csound requires only adding a few lines to
the one Makefile.am.

Before committing the files, I also plan to ensure that the build system
makes
everything on Red Hat Linux, that I can render some pieces all the way
through, and that at least some of the utilities work. I also need to get
the Csound API library built as a shared library; currently opcodes build as
shared libraries, but not Csound itself.

Summary of changes:

I introduced one Makefile.am to build all targets.

I renamed some files in the anal and util directories to avoid duplicate
filenames.

Most opcodes are now working plugins.

I moved a few opcodes from Opcodes back to OOps due to complex
interdependencies.

The Csound console executable links with the Csound API.

I added code to csoundLoadExternals to automatically load all plugin opcodes
in $OPCODEDIR (on systems with dirent.h).

I added a Top/ustub.c file to work with ustub.h and to replace duplicate
code collected from utility sources.

I added a libustub.a library containing ustub.c and a good chunk of csound
to link all utilities.






============================================
Michael Gogins
gogins at pipeline period com
Irreducible Productions
CsoundVST, an extended version of Csound for programming music and sound
Available at http://sourceforge.net/projects/csound/
============================================

Hi Michael,

Would it be possible to put up a tarball of the sources as you have them
somewhere online?  I think it'd be easier to debate if we could see what
the Makefile.am looks like, see the rest of the changes to the source,
as well as try out the build system.  (I think it's been a long day for
me as I'm having a hard time visualizing all the things that you've
done!)

Either way, looking forward to checking out all of this!

Thanks!
steven




On Sun, 2004-02-08 at 19:37, Michael Gogins wrote:
> I have a new build system based on a single Makefile.am that now succeeds in
> building the Csound API library, the Csound console executable linked with
> the the API library, all the plugin opcodes, and all the utilities on Cygwin
> (using the Cygwin dll). The system links with the FLTK GUI and windows,
> PortAudio, Windows MIDI, and libsndfile.

"Michael Gogins"  writes:

> I have a new build system based on a single Makefile.am that now
> succeeds ...

Congratulation!

> Before committing any files, I would like to know what John Fitch
> and others would prefer. The options are:

My first piece of advice is to tag often so that one can return to a
consistent sets of files with ease.  Descriptive tags would be very
nice.

> 2. I can branch the Csound 5 package, and development of Csound 5 with the
> Makefile.am system can continue in the new branch.

If you are reasonably confident in the new system, I think you should
branch the Csound 5 package, and development of Csound 5 *without* the
Makefile.am system should continue in the new branch.  Should there be
a reason to abort development of the Makefile.am based system, the
branch can be merged back into the main line and then abandoned.

John