It would be fantastic if you do CVS and SourceForge. I don't know if there
is a GUI client for Macs, but I find that the WinCVS GUI client makes using
CVS much easier.

Basically, there are good directions at SourceForge for using all these
tools. You will need to make a cryptographic key for yourself to use CVS
most easily (explained on the site).

Things will go so much faster and more smoothly if we are all actually
working with the same code!...

============================================
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: "Matt J. Ingalls" 
To: "Csound Developers Discussion List" 
Sent: Sunday, November 16, 2003 7:03 PM
Subject: [CSOUND-DEV:3345] Re: csound.c in csound5 cvs


>
> i have a bunch of changes to that buffer stuff
> that should
> fix things like
> that i can send to you if you
> want - or maybe its time i figure out sourceforge...
>
> -m
>
> On Sun, 16 Nov 2003, stevenyi wrote:
>
> > Hi all,
> >
> > I'm working on getting csound.c working with csound5 cvs and have a
> > couple of questions.  The latest version I just checked in has
> > references to runincomponents changed to frsturnon, as that seemed liked
> > the correct change looking at code from musmon.c and widgets.cpp.
> >
> > One change I needed to make was this:
> >
> > /* warning("Exceeded maximum number of environment paths"); */
> >         csoundMessage(csound, "Exceeded maximum number of environment
> > paths");
> >
> > Is this the correct way to do it?  (this is lines 973-974 in the latest
> > csound.c in csound5 cvs).
> >
> > Now in compiling this latest version, all I have left is an undefined
> > reference to inbuf, line 305.  This is in the function:
> >
> >  void *csoundGetInputBuffer(void *csound)
> >   {
> >     return inbuf;
> >   }
> >
> > which I'm having a hard time finding.  Any ideas here?
> >
> > Thanks,
> > steven
> >
> >
>

There seems to be MacCVS  which is a mac veresion of WinCVS.

http://cvsgui.sourceforge.net/download.html

I happen to use the Eclipse IDE for coding all of my java, c/c++,
python, and php projects now.  I'm quite fond of it's CVS features. 
Eclipse is available on osx, windows, and linux.

It also looks like Apple's XCode dev environment has support for cvs,
but the docs are a bit unclear.

steven

On Sun, 2003-11-16 at 18:18, Michael Gogins wrote:
> It would be fantastic if you do CVS and SourceForge. I don't know if there
> is a GUI client for Macs, but I find that the WinCVS GUI client makes using
> CVS much easier.

In an effort to advance the introduction of automake and libtool into
csound, but not wanting to interfere with the efforts taking place in
the csound5 module, I added an automake and an autoconf file into the
csound module.  You can try it out by typing

  $ autoreconf -i

The configure.ac file was mostly derived from the one in csound5.  It
currently simply enables libtool and disables the production of shared
libraries.  Here is the libtool section.

  # Turn off shared libraries during beta-testing, since they
  # make the build process take too long.
  AC_DISABLE_SHARED

  dnl The libltdl API is similar to the dlopen interface of Solaris and Linux
  dnl AC_LIBLTDL_* enable generic interface to runtime dynamic linking 
  dnl AC_LIBTOOL_DLOPEN check for dlopen support
  dnl AC_LIBTOOL_WIN32_DLL check for clean dlls on win32 platforms
  AC_PROG_LIBTOOL

To windows gurus, should I uncomment AC_LIBTOOL_WIN32_DLL?  What does
the phrase "clean dlls" mean?

When I get a chance to get back to csound, I plan to try out libltdl.
This feature makes it so that libtool handles all the platform
differences, and csound sources need only program to one interface.
The libtool documentation says it supports dynamic linking for
Solaris, Linux, various BSDs, HP-UX, Win16 and Win32 LoadLibrary and
BeOS.  I think MacOS X is considered a BSD, but that is one thing that
needs to be tested.

This exercise forced me to look very closely at the configure.in file
in the csound5 module.  It seems to make many unused tests.  For
example, it contains

  AC_CHECK_LIB([X11], [XOpenDisplay])

but it's not clear why.  How was configure.in written?  Are there
tests in that file as a result of simply starting with an existing
configure.in file?

Also, I fixed the checks for the existence FLTK.  These changes should
be merged back into configure.in.

One final note on configure.ac.  It currently contains a large
dispatch with is used to define the audio and gui objects that should
be included in the library just as does configure.in.  I realize now
that when using automake, configure.ac should use AM_CONDITIONAL to
indicate the platform, and then the object file selection should occur
in the Makefile.am file, conditionalized on the variables defined
using AM_CONDITIONAL.

The current Makefile.am builds and installs only csound, and
libcsound.  Once AM_CONDITIONAL's are included into configure.ac, it
will be easy to build the utilities in anal, util1, and util2, via a
Makefile generated from the top-level Makefile.am.  Since the purpose
of this Makefile.am is to facilitate the addition of Makefile.am's to
the csound5 module, it's not clear there is a reason to add these
build targets, unless the csound5 release is not expected soon.

I found a very nice example of the use of autoconf and automake.  The
strace utility appears to be written by people well versed with these
tools.  You may want to read their source, which is available from:

http://sourceforge.net/projects/strace

Note their use of AM_CONDITIONAL's.

John

And emacs has cvs code.  Personally I prefer command lines though.
Worked brilliantly on my mac.
==John ffitch

>>>>> "John" == John D Ramsdell  writes:

 John> This exercise forced me to look very closely at the configure.in file
 John> in the csound5 module.  It seems to make many unused tests.  For
 John> example, it contains

 John>   AC_CHECK_LIB([X11], [XOpenDisplay])

 John> but it's not clear why.  How was configure.in written?  Are there
 John> tests in that file as a result of simply starting with an existing
 John> configure.in file?

That test was there to see if winX11.c is a valid thing to include.
configure.in was written my me with some assistance from Owen Cliffe
and some tool or other.  It may indeed not be complete

==John ffitch

jpff@codemist.co.uk writes:

> >>>>> "John" == John D Ramsdell  writes:
> 
>  John>   AC_CHECK_LIB([X11], [XOpenDisplay])
> 
> That test was there to see if winX11.c is a valid thing to include.
> configure.in was written my me with some assistance from Owen Cliffe
> and some tool or other.  It may indeed not be complete

The reason I asked about this particular test is my RH9 platform
answers no to this query, but it clearly has X11.  If I ensure the
configure script cannot find FLTK, it builds a csound program that
draws graphs in ASCII, even though winX11.o is found and added to
libcsound.  

I'll trace this issue down.  In fact, I'll go through the configure.ac
file line-by-line, and carefully analyze it.  Expect more questions.

I also volunteer to write a test to determine how GCC wants its
alignment flags.  This bit with specifying --with-gcc3 has got to go!

Thanks for your help.

John

> I also volunteer to write a test to determine how GCC wants its
> alignment flags.  This bit with specifying --with-gcc3 has got to go!

Please do!  I put that in as I couldn't figure out a proper way to do it
and it was the quickest solution (hack).  

steven

Steven,

I think the trick to setting the cflags correctly in
csound5/configure.in is this sequence of commands:

AC_PROG_CC
if test "x$GCC" = xyes; then
  case `$CC -dumpversion 2>/dev/null` in
    [12].*) 
      ALIGN_FLAGS="-malign-loops=4 -malign-jumps=4";;
    *) 
      ALIGN_FLAGS="-falign-loops=4 -falign-jumps=4";;
  esac
  CFLAGS="$CFLAGS -Wall $ALIGN_FLAGS -ffast-math -fomit-frame-pointer"
  CFLAGS="$CFLAGS -finline-functions -funroll-loops"
fi
AM_PROG_CC_STDC

John

stevenyi  writes:

> > I also volunteer to write a test to determine how GCC wants its
> > alignment flags.  This bit with specifying --with-gcc3 has got to go!
> 
> Please do!  I put that in as I couldn't figure out a proper way to do it
> and it was the quickest solution (hack).  
> 
> steven

Are you going to/have you committed that yet?
Sounds good
==John

John,

To avoid talking past one another, I would like to make sure I
understand your intended design goals for a configure script for
csound, as I suspect they differ from what is actually implemented.
Here is what I think was intended.

For every platform that supports FLTK (i.e. makes available an
fltk-config script), use winFLTK.o and FL_graph.o as the graphing
objects, and widgets.o as the FLTK object, unless --with options say
otherwise.  Also, define WINDOWS.

For every platform that does not support FLTK, but does support X11,
use winX11.o as the graphing object, and define WINDOWS.

If WINDOWS is still not defined, and the operating system is some
flavor of Windows, use window.o as the graphing object (is this
right?) and define WINDOWS.

Finally, based on the operating system, select the appropriate
real-time audio object files, unless --with options say
otherwise.  Also, define RTAUDIO.

Is it true that the only platform specific test required to correctly
configure Csound is the host's operating system?  In other words, will
$host_os always be sufficient for all configuration needs?

Also, is there any reason one would want to use FLTK, but not use the
GUI?  In other words, shouldn't USE_FLTK imply USE_GUI?

One final question, was that other tool used to build configure.in by
you or Owen Cliffe autoscan?

John

jpff@codemist.co.uk writes:

> >>>>> "John" == John D Ramsdell  writes:
> 
>  John> This exercise forced me to look very closely at the configure.in file
>  John> in the csound5 module.  It seems to make many unused tests.  For
>  John> example, it contains
> 
>  John>   AC_CHECK_LIB([X11], [XOpenDisplay])
> 
>  John> but it's not clear why.  How was configure.in written?  Are there
>  John> tests in that file as a result of simply starting with an existing
>  John> configure.in file?
> 
> That test was there to see if winX11.c is a valid thing to include.
> configure.in was written my me with some assistance from Owen Cliffe
> and some tool or other.  It may indeed not be complete
> 
> ==John ffitch

I've been committing updates to the csound module in a way that does
not break anyone.  You get ordinary csound behavior unless you type
"autoreconf -i", in which case, you can try my experimental
configure.ac and Makefile.am.  The current version of configure.ac is
not done yet, but if you want to play with it, be my guest.  I'll send
out a message when I'm looking for testers.  Once the configure script
is solid, I'll help merge it with Micheal's configuration efforts in
the csound5 module.  I have no idea where he is in that process.  I
would like to explore the libtool features completely before moving
the results into the csound5 module.  Help understanding the
AC_LIBTOOL_WIN32_DLL autoconf macro would be greatly appreciated.
Here is the info on it.  Should I enable it?

 - Macro: AC_LIBTOOL_WIN32_DLL
     This macro should be used if the package has been ported to build
     clean dlls on win32 platforms.  Usually this means that any
     library data items are exported with `__declspec(dllexport)' and
     imported with `__declspec(dllimport)'.  If this macro is not used,
     libtool will assume that the package libraries are not dll clean
     and will build only static libraries on win32 hosts.

     This macro must be called *before* `AC_PROG_LIBTOOL', and
     provision must be made to pass `-no-undefined' to `libtool' in
     link mode from the package `Makefile'.  Naturally, if you pass
     `-no-undefined', you must ensure that all the library symbols
     *really are* defined at link time!

John

John ffitch  writes:

> Are you going to/have you committed that yet?
> Sounds good
> ==John

For those of you modifing configure.{in,ac} or any other shell
scripts, I plead for caution when writing tests.  A test of the form:

   test "$VAR" = val

or

   test "$VAR"

will often do bad things if the value of $VAR starts with a hyphen.
Instead one should write 

   test "x$VAR" = xval

and

   test -n "$VAR"

If you read the configure script that comes with FLTK, you'll note the
author writes this kind of defensive code.

John

Hi John R,

I apologize: my previous email was incorrect.  This bit of code works
just fine and I had misread it when trying to use it the first time.  I
think though that some of the flags here added in CFLAGS might be better
later in the script as part of XCFLAGS, but I'm not sure as I have no
idea if these flags are relevant to other hosts (the host test code
starting at line 149 in the csound5 cvs, revision 1.7).  Also seems that
there are no host tests to configure for MacOS9 or OSX yet. 

Thanks very much for figuring this part out!

steven

p.s. - csounds.com is up but the email server is not letting me login to
get my mail via pop (currently ssh'ing in to use 'mail' to check mail). 
I've been meaning to reply to some of the recent posts but am waiting
for pop access to clear up; apologies ahead of time if my replies to
conversation are a bit delayed.
 

On Wed, 2003-11-19 at 03:29, John D. Ramsdell wrote:
> Steven,
> 
> I think the trick to setting the cflags correctly in
> csound5/configure.in is this sequence of commands:
> 
> AC_PROG_CC
> if test "x$GCC" = xyes; then
>   case `$CC -dumpversion 2>/dev/null` in
>     [12].*) 
>       ALIGN_FLAGS="-malign-loops=4 -malign-jumps=4";;
>     *) 
>       ALIGN_FLAGS="-falign-loops=4 -falign-jumps=4";;
>   esac
>   CFLAGS="$CFLAGS -Wall $ALIGN_FLAGS -ffast-math -fomit-frame-pointer"
>   CFLAGS="$CFLAGS -finline-functions -funroll-loops"
> fi
> AM_PROG_CC_STDC
> 
> John

> ... I think though that some of the flags here added in CFLAGS might
> be better later in the script as part of XCFLAGS, ...

Steven,

The configure.ac script in the csound module changed how X_CFLAGS was
used.  The original manor in which it was used interacted poorly with
the fltk-config script, and also caused inaccurate results to be
reported from AC_CHECK_LIB([X11], [XOpenDisplay]).  You can instantly
guess something is wrong in a configure script if you find code that
uncoditionally assigns LDFLAGS.  The updated version adds fltk-config
info to CFLAGS, CXXFLAGS, LDFLAGS, and LIBS, when available, otherwise
it adds $X_CFLAGS to CFLAGS and $X_LIBS -X11 to LIBS, and then
performs AC_CHECK_LIB([X11], [XOpenDisplay]).  The correct answer is
derived in this context.

This weekend, rain is predicted, so I'm sure I'll have time to finish
debugging the configure.ac script in the csound module.  Once it is
tested, I'll consult with Micheal about integrating its features into
the csound5 module.  It shouldn't be very tricky, but I want to be
sure not to break anything.

John

stevenyi  writes:

> Also seems that there are no host tests to configure for MacOS9 or
> OSX yet.

What string does $host get bound to for these operating systems?  I'll
make cases for these when I find out.  Also, in the current script,
Linux Be is identified by finding Linux as the OS and then checking to
see if the byte order is big endian!  This is clearly broken as it
would misidentify SPARC Linux.  What string does $host get bound to
for Linux Be?

These are the kind of things I want sort out before the csound5
configure.in script is modified.

Additionaly, the msys settings are wrong.  The libcsound source code
will not compile with the flags given on my Windows 2000 laptop.  I'll
look into this too.

John

Thanks, John! I knew something was wrong there, but could not point it out.
(Msys)
As for OSX, beats me. Someone must try a tool chain for it and tell us.
Darwin comes to mind. I think OSX is Darwin.


-----Original Message-----
From: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu]On Behalf Of John D. Ramsdell
Sent: Friday, November 21, 2003 6:07 AM
To: Csound Developers Discussion List
Subject: [CSOUND-DEV:3453] Re: Going without --with-gcc3


stevenyi  writes:

> Also seems that there are no host tests to configure for MacOS9 or
> OSX yet.

What string does $host get bound to for these operating systems?  I'll
make cases for these when I find out.  Also, in the current script,
Linux Be is identified by finding Linux as the OS and then checking to
see if the byte order is big endian!  This is clearly broken as it
would misidentify SPARC Linux.  What string does $host get bound to
for Linux Be?

These are the kind of things I want sort out before the csound5
configure.in script is modified.

Additionaly, the msys settings are wrong.  The libcsound source code
will not compile with the flags given on my Windows 2000 laptop.  I'll
look into this too.

John

I finally caught up by reading over 200 posts from this list last night (The
last two months for me have been comsumed by moving, etc. and haven't left
much time for reading mail).

There were a few old posts that I would still like to briefly comment on --
please forgive my very late responses :)

On 11/21/03 7:06 AM, John D. Ramsdell etched in stone:

> stevenyi  writes:
> 
>> Also seems that there are no host tests to configure for MacOS9 or
>> OSX yet.
> 
> What string does $host get bound to for these operating systems?

Well, I think you eventually figured out that OS X was something like
powerpc-apple-darwinX.x.  Regarding OS 9, there is of course NO string for
$host as the autotools (to the best of my knowledge) have never been ported
to the Legacy Mac platform.  Someone will simply have to do the
configuration for that platform by hand (me, I suppose, since there seems to
be very little interest otherwise).

That's fine since we are using a completely different build system
(CodeWarrior) on this platform.  I am tempted to try to get Csound compiling
with Apple's free MPW tools as well.  There are even old versions of GCC
available for that environment.  (Makes me wonder if the autotools _could_
be ported to MPW, but now I'm just babbling ...)

Anthony Kozar
anthony.kozar@utoledo.edu