I see a top-level Makefile.jpff in Csound 5 CVS, but I do not see any of the
makefiles it references (makefiles in subdirectories).

Where are the makefiles that John Fitch uses for Csound 5? It would help me
get scons in synch with the makefile build if I could see them.

============================================
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: "Michael Gogins" 
To: "Csound Developers Discussion List" 
Sent: Tuesday, March 16, 2004 8:32 PM
Subject: [CSOUND-DEV:4351] Re: IMPORTANT - Re: Getting in step


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

The Makefile.in files used to be in the CVS.  I assume they got
deleted somewhere along the way.
==John ffitch