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?

Original Message:
-----------------
From: stevenyi stevenyi@csounds.com
Date: Sun, 22 Aug 2004 09:38:49 -0700
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:5244] Re: Csound Manual - gdp-both.dsl


Last I emailed with Kevin, he had finished working on the ACRM and had
placed all of his docbook source files and makefiles into CVS so that
the
community can continue on with the manual.  He is no longer is
maintaining or working on the manual as the stress and time involved was
less enjoyable than it had been, and has moved on to other things. I
thanked him for all of his hard work and wished him well, as I believe
everyone here would too.

I think he's left the manual in CVS in great shape for all of us to
continue on with his work, keeping things up to date, and continuing to
make Csound one of the best documented open-source music tools around.  

steven


On Sat, 2004-08-21 at 19:58, Anthony Kozar wrote:
> What happened to Kevin anyways?  I noticed a couple of months ago that
he
> was no longer listed as a developer on Sourceforge.  Did I miss an
email
> somehow saying that he was resigning?
> 
> Anthony
> 
> 
> On 8/21/04 9:53 PM, stevenyi etched in stone:
> 
> > Hi All,
> > 
> > I was making edits to the Csound Manual in CVS to update it's status
a
> > community project and also to bring it up to date as now no longer
being
> > the "Alternative" manual but "Canonical".  My edits worked out fine,
but
> > the copy of gdp-both.dsl that I attained must not be the same as the
one
> > used by Kevin as the generated output differs somewhat (list of
tables
> > being generated on index page, etc.).  Does anyone have a copy of
> > gdp-both.dsl that generates the manual as Kevin's did?  
> 
> 


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

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?

On 8/22/04 5:31 PM, stevenyi etched in stone:

> For the time
> being, though, I think it'd be best to have the manual repository as is
> for csound4 documentation,

Agreed.

> and then also to make a copy of the manual
> within the csound5 cvs which will cover csound5 program usage, opcodes,
> development, etc.

Not sure that this should be in the same module.

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

Exactly.  The addition of the binary files has already made it rather
tedious.

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

Sounds good to me.

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

There should be a user-accessible place for opcode libraries as well.  These
locations will also have to platform dependent.  (eg.  At least on OS X
10.2, /usr/local/bin is not in the default path).

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

Agreed.

I also think that building the documentation should be separate.  Since the
output of the doc build is platform-independent HTML, it is not as likely a
target to be custom built by users as the csound executables themselves
would be.  I think that I would even prefer the documentation source to not
be included in the source distributions - but I could see that being argued
the other way.

> For installers, what are the preferred options?
> [...] for OSX to put together a dpkg,

No.  I think .dmg (disk image) with an Apple installer package inside is
preferred (or is that what a dpkg is?).

> and for windows to use
> NSIS (http://nsis.sourceforge.net/).

I think John R. has already worked out an NSIS installer for Csound 4.

Anthony

Hi Anthony,

> 
> > For installers, what are the preferred options?
> > [...] for OSX to put together a dpkg,
> 
> No.  I think .dmg (disk image) with an Apple installer package inside is
> preferred (or is that what a dpkg is?).

I think you're right and I was going off faulty memory (I think dpkg is
used with Fink...?).  I'm not an OSX guru by any means so if anyone
knows what the preferred method of installer is for installing console
applications, please let us know.  (I'll ask my OSX developer buddy at
work tomorrow as well).

> > and for windows to use
> > NSIS (http://nsis.sourceforge.net/).
> 
> I think John R. has already worked out an NSIS installer for Csound 4.

Neat!  I didn't notice it before as it was in the flCsound directory;
I'll try to start on using it for Csound5 when I have a chance.  Also,
I'll try to work on an "installer" target in the Scons file as suggested
by Michael.

steven