If I work on the documentation, I'll choose whatever method seems to be
best -- which mainly means easiest and quickest. LaTeX has been fantastic
for me so far, but I would certainly check out SGML.

I agree about scons, it would be nice to have fewer targets and more clearly
worked out dependencies. I may be deal with this when I take Cygwin out as I
am planning to do.

If you do an NSIS installer, please try to make it a target in SConstruct.
You may also be able to the same for an RPM. scons has the ability to
execute any shell command, sequence of commands, or script in a "command"
target.

----- Original Message ----- 
From: "stevenyi" 
To: "Csound Developers Discussion List" 
Sent: Sunday, August 22, 2004 5:31 PM
Subject: [CSOUND-DEV:5249] Re: Csound Manual - gdp-both.dsl


> Hi Michael,
>
> Combining the manual and csound.pdf sounds fine to me.  For the time
> being, though, I think it'd be best to have the manual repository as is
> for csound4 documentation, and then also to make a copy of the manual
> within the csound5 cvs which will cover csound5 program usage, opcodes,
> development, etc.  That might be an issue though as the manual in CVS is
> currently at 11 megs in size, making a fresh checkout from CVS that much
> longer to do.  (I think at this rate, it would take Gabriel and others
> on modem a whole day to download csound5 from CVS, especially with all
> of the binary libraries and snapshots in there...).
>
> Also, I would suggest to move the csound.pdf documentation from Latex to
> using Docbook SGML to match how the rest of the manual works.
>
> As an aside, I think we need to work out the Scons file a bit to
> separate out build targets more clearly.  Instead of having to declare
> flags to "build everything except...", I think we need to restructure to
> "build this target which may include other targets".  Target I imagine:
>
> all (defaults to csound target)
>
> libcsound
> csound - depends libcsound
>
> csoundVST - depends libCsound, and other dependencies
>
> doc - generates documentation in HTML and PDF
>
> release - depends on csound and doc target, puts together src.tar.gz,
> bin.tar.gz, bin.zip, installers, RPM's, .debs, etc.
>
> releaseCsoundVST - depends csoundVST and doc, builds as above
>
> install - (unix-based systems only) - install binary to /usr/local/bin,
> opcode libraries to /usr/local/share/csound (any suggestions better
> where this should go?)
>
>
> In general, I would like to see the csoundVST build as separate from the
> main build as the dependencies are not as simple as those of csound
> itself.  I have to run "scons buildCsoundVST=0" just to compile csound5
> without csoundVST, which really seems backwards rather than saying
> "scons csoundVST" to say I want to build it.  I think also that using
> the "key=value" syntax on commandline for feeding scons options should
> be changed a bit as some of these should be build targets fed to scons
> rather than configuration options.  (I'll be looking into the SCons file
> starting in the middle of the week to see if I can reorganize it a bit.)
>
> For installers, what are the preferred options?  I'm thinking for Linux
> to build RPM's, for OSX to put together a dpkg, and for windows to use
> NSIS (http://nsis.sourceforge.net/).  I'm suggesting NSIS as it's the
> one I've tried out before and it's free to use, but any other
> suggestions would be welcome.  If no one objects, I will put a
> "installer" directory within the csound5 repository with subdirectories
> "windows", "linux", and "macosx" to at least have something there for
> people to start thinking about.  I will start an NSIS installer script
> for csound5 later this week as well if no one voices a different
> option.  I believe there is an RPM script in the csound4 cvs to use as a
> start for csound5.
>
> steven
>
>
>
>
>
>
> On Sun, 2004-08-22 at 10:31, gogins@pipeline.com wrote:
> > If Kevin is no longer involved, then I think we could carry on his
> > excellent work in a somewhat more streamlined way by combining
csound.pdf
> > and the ACRM into a single csound.pdf file using LaTeX and Doxygen. We
> > could also make the build produce the documentation automatically, and
> > include documentation for contributed plugin opcodes that get built.
> >
> > What do you think?
>