Currently the files are not in synch. There are two ways to fix the
situation:

(1) Remove Makefile.jpff and use scons.

(2) Make sure that Makefile.jpff and scons build the same targets from the
same sources with the same #ifdefs.

It is NOT POSSIBLE to simply fix up SConstruct to make exactly the same
targets with exactly the same sources as Makefile.jpff, mainly because such
a build could not run on Windows.


When I started working in Csound 5, the plugin opcodes were not loading.
This is because dynamic libraries on Windows can't contain unresolved
symbols. Therefore I moved some files from OOps to Opcodes.

These changes are REQUIRED for a Windows build because the symbols in
question cannot be referenced from one plugin to another on Windows; they
have to be in the Csound engine.

This was the first inconsistency between John Fitch's work and my own.

Then I noticed that the utility programs contained many duplicate functions,
err_printf, synterr, and others. John Ramsdell had already created for his
GNU build system a convenience library to contain this code, libanal.a,
which I adopted and renamed libustub.a (because it is not used only for
analysis programs). Then of course I deleted that code from the utility
sources. These changes went into my version of the GNU build system and into
the SCons build file, SConstruct. These changes are not required, it simply
seemed like a good idea to fold together redundant code.

This was the second inconsistency.

Finally I have removed jpff_glue.c from CVS and changed the code to use
csound.c, and to link the Csound console executable to the Csound API
library. John Fitch is still using jpff_glue.c. Using csound.c is not
required, but it is HIGHLY ADVISABLE to ensure that the console version of
the Csound and the API version of Csound frender scores in the same way.

I have announced all of these changes on csound-dev and documented them in
my files.

The problem with this inconsistency is that now I will make updates that
break some changes made by people working with the makefile system, and
people working with the makefile build system will break some changes made
by me or others working the new build system.




============================================
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/
============================================


----- Original Message ----- 
From: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, March 16, 2004 12:36 PM
Subject: [CSOUND-DEV:4345] Re: Getting in step


> The "unknown problem" is only unknown to you as your static makefiles
> work for you without you ever having to touch them.  If a good number of
> us here are looking at auto-configuring build systems, don't you think
> maybe there's a real issue at hand and denying that a problem exists
> really won't help get Csound to build on everyone else's computer?
>
> I have never had Csound build out-of-the-box except in the cases of the
> Autotools build for Csound4 and now the SCons system in Csound5.
>
> Autoconf and SConstruct both address the same issues of analyzing the
> system being built on and building the sources depending on what's
> available.  By automating this, builds becomes easier to do as the
> person building doesn't have to spend time tracking what they have and
> configuring the Makefile as it configures itself.
>
> Regardless, the build system issue is a moot point now.  You have your
> Makefile's in the CVS.  The SConstruct file does not generate any files
> that can possibly overwrite your Makefile's (as was the case with the
> Autotools).  The two systems can coexist without problems so hopefully
> we can all have access to build systems that will work for each of us.
>
> The only thing now is to keep them in sync, so if files are reorganized
> in one build system that they are updated in the other build system.
>
> As for ustub, please see:
>
>
http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00005.html
>
http://eartha.mills.edu:8000/guest/archives/CSOUND-DEV/log0402/msg00007.html
>
> I guess I was aware of it from the autoconf builds as well as from
> reading the CVS annotations when doing updates; I can see how it may
> have gotten missed though.
>
> steven
>
>
> On Mon, 2004-03-15 at 23:51, jpff@codemist.co.uk wrote:
> > As far as I could see there was no CVS build.  I have been unable to
> > build from autoconf for weeks and weeks.  The code I have here
> > certainly compiles and runs.
> >
> > I was unaware of any ustub library; does it have a description?  Did
> > not see any mail about it.  If I knew what it was I might use it.  I
> > am aware that the CVS system does not build -- but my code does.
> >
> > I do not know the answer to
> > > If you want me to change SConstruct to build the same targets from
> > > the same sources as your makefiles, I will do that
> > as I know nothing about SConstruct.  You may be aware that I have
> > repeatedly asked what the purpose of autoconf is, and this seems to be
> > more code to solve an unknown problem
> > ==John ffitch
> >
> >
>