Csound Csound-dev Csound-tekno Search About

[CSOUND-DEV:3754] Re: Csound GNU build system lessons learned

Date2003-12-14 15:33
From"Michael Gogins"
Subject[CSOUND-DEV:3754] Re: Csound GNU build system lessons learned
Thanks for your work with autotools. If I had the time I would have done
much the same. I propose that we proceed to reorganize the directories for
csound5. I suggest the standard pattern as you say; elaborating this, I
suggest the structure outlined below.

I would appreciate hearing from other Csound developers and especially from
John Fitch on this structure. One major feature of this structure is that
the csound/src/csound directory contains all the original Csound sources and
does NOT contain any projects with external dependencies (no third party
libraries such as FLTK or the VST SDK).

csound
    src
        csound // traditional csound slightly reorganized, no external
dependencies
            kernel // csound API - most current Csound files; builds a
shared library of the Csound API
            console // ccsound, built as a client of the API
            utilities // used to be anal, but with each program in a
separate subdirectory
                hetero
                cvanal
                etc...
        wxCsound // replacing Winsound
        vst // CsoundVST
            pyrun
            CsoundVST
            CsoundVSTWin
            vst2sdk // each developr must download this from Steinberg;
configure.ac merely assumes it to be here
        opcodes // plugin opcodes
            fluid
            fltk
            // others as broken out by John Fitch or as contributed
    lib
    bin
    doc
            manual // Csound manual (??? already a separate SourceForge
project ???)
            html // API and plugin documentation from Doxygen

If we can't get libtool to build Windows DLLs, then we should drop libtool
and just use custom rules in the Makefile.am's. Probably we will only need
custom rules for Unix/Linux, for Macintosh, and for Windows. These can be
derived from the existing, pre-autotools makefiles. I have done this for
commercial software. I haven't spent much time trying to get libtool to work
for Windows, though. I will troll through the mailing lists and see what
others have found. Even with these custom rules, the autools build system
would still be much simpler than the older system.

As for FLTK and tabbed panels, CsoundVST has tabbed panels, so I'm not sure
what you're talking about. But my position with respect to windowing and
Csound is pretty much the same as John Fitch's: windows and other GUI code
don't belong in the Csound kernel, but should be placed in programs that use
Csound via the API or in plugin opcodes. Since the GUI opcodes and CsoundVST
already use FLTK, it would reduce external dependencies if wxCsound also
used FLTK, but I don't really care.

The Csound API allows hosts to set a yield callback with
csoundSetYieldCallback. I suggest that the FLTK stuff be turned into a
plugin opcode that's part of the autools build, and this opcode should call
csoundSetYieldCallback to set a hook that calls Fl::check.

============================================
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: "John D. Ramsdell" 
To: "Csound Developers Discussion List" 
Sent: Sunday, December 14, 2003 8:29 AM
Subject: [CSOUND-DEV:3753] Csound GNU build system lessons learned


> For some reason, the following message did not make it out yesterday,
> so I have reposted it.
>
> John
>
> From: ramsdell@mitre.org (John D. Ramsdell)
> Subject: Csound GNU build system lessons learned
> To: Csound Developers Discussion List 
> Cc: ramsdell@mitre.org
> Date: 13 Dec 2003 11:51:36 -0500
>
> Even though the GNU build system in the csound module has yet to be
> completed, I would like to relay lessons learned that I think should
> be reflected in the GNU build system in the csound5 module.  The
> biggest deficiency in the csound module's current GNU build system is
> its inability to build shared libraries, so I will not comment on the
> wisdom (or lack of wisdom) of using libtool.  In suffices to say that,
> so far, libtool's only function has been to slow down builds.
>
> The three tools that have demonstrated their usefulness are autoconf,
> autoheader, and automake.  To better support autoheader, each
> AC_DEFINE statement in the csound module's configure.ac contains a
> documentation string.  The result is a nicely commented config.h.in
> file.
>
> Unlike autoconf, which has been a solid tool for a long time, older
> versions automake were not easy to use, however, the current version
> of automake is very solid.  Not only is there mature support for C,
> and C++ programs, but the version on my machine provides support both
> Python and Java programs.  Of course, for Java programs, automake
> requires you use gcj, the Java front-end to the GNU Compiler
> Collection.  I ask this of anyone not convinced of the merits of
> employing automake in the csound5 module: please compare
> anal/adsyn/Makefile.am with anal/adsyn/makef.  I'm sure you'll see
> that the automake version of this information is much more
> understandable.  The real understandability test is to compare
> csound/Makefile.am with csound/Makefile.lnx.
>
> It is easy to employ automake if your project follows two rules.
>
> 1. Source files should be placed only in directories that do not
>    contain directories, other than CVS.
>
> 2. To the extent possible, sources used to build a product, such as a
>    program or a library, should be placed in the directory in which
>    the product is built.  This rule does not apply to header files,
>    which can be included from arbitrary directories.
>
> With respect to the first rule, automake makes use of a commonly
> respected convention on the organization of source files that existed
> long before automake.  Unix programmers following the convention
> always know that a directory contains no directories by simply noting
> the existence of file names of sources.  With this convention, there
> is no need to employ typographical conventions to identify
> directories, such as capitalizing directory names or adding a .dir
> extension.
>
> The second rule used to be strictly enforced by automake, however, the
> current version of automake allows exceptions to both rules.  Violate
> these rules with caution.
>
> --------------
>
> What follows is a list issues presented in no particular order.
>
> The GNU build system in the csound module includes the csound/config.h
> file generated by configure.ac only in the file csound/autoheader.h,
> and other parts of the package include autoheader.h.  This
> arrangements makes it easy to augment definitions in config.h.  By the
> way, I'm not in love with name autoheader.h--you may want to change
> it.
>
> At some point, to handle C99 booleans, autoheader.h should include
>
> #if HAVE_STDBOOL_H
> # include 
> #else
> # if !defined HAVE__BOOL
> #  ifdef __cplusplus
> typedef bool _Bool;
> #  else
> typedef unsigned char _Bool;
> #  endif
> # endif
> # define bool _Bool
> # define false 0
> # define true 1
> # define __bool_true_false_are_defined 1
> #endif
>
> To handle C99 booleans, source files must be changed.
>
> The tool autoscan helps produce a configure.ac script.  I notice that
> when it generates its AC_CHECK_HEADERS macro call, it makes sure there
> are no line breaks in its argument.  The same is true for
> AC_CHECK_FUNCS macro call.  I bet if the line breaks in the argument
> to AC_CONFIG_FILES are removed, that file could be a text file once
> again.
>
> The use of FLTK in the library that implements the Csound API raises a
> number of issues.
>
> In csound/csound.c, the csoundYield function must conditionally cause
> the invocation of Fl::check().  If it does not, the main routine in
> csound/ccsound.c cannot use the FLTK graphing routine, since it has
> access only to symbols declared public in libcsound, in other words,
> it can only use symbols in the Csound API.
>
> In configure.ac, the fltk-config program is consulted to obtain its
> opinion on how to link FLTK programs.  On Cygwin, the -mwindows option
> is included, under the assumption that no one would ever want to use
> FLTK with a console application, but, of course, console csound does
> just that.  I've currently turned off the use of FLTK on Cygwin.
>
> When building wxCsound on a platform that has FLTK installed, one
> finds one must link the wxcsound program with both wxWindows libraries
> and FLTK libraries.  This does not feel right to me.
>
> I considered reimplementing wxCsound using FLTK, but found wxWindows
> provided much better support for Windows.  For example, wxWindows
> provides a tabbed window pane that maps directly to the Windows
> equivalent, but I cannot see how to obtain the same functionality with
> FLTK.
>
> The wxCsound package is distinct from the csound package.  The
> csound-config program is consulted to obtain its opinion on how to
> link programs that use the Csound API.  One might consider making
> CSoundVST into its own distinct package, one that is configured using
> csound-config.
>
> The wxWindows configure.in file contains advice on linking with MinGW.
> In particular, it can be wrong to include -lm at link time.  As such,
> I've changes the test for this library in configure.ac to:
>
>   AC_SEARCH_LIBS([sin], [m])
>
> --------------
>
> It is time to begin planning for a revamped GNU build system for the
> csound5 module.  There is no reason to delay work on a libtool-less
> system.  The first issue that must be addressed is the directory
> organization.  Perhaps the current one already meets the two rules
> previously listed, however, now is the time introduce a top-level src
> directory, a doc directory, and/or an include directory, or whatever
> other changes you want that are independent of the reorganization in
> support of automake.
>
> The directory reorganization in support of automake should be directed
> by someone with a vision of what Csound will be, i.e., not me.  I have
> been able to succeed because I have been dealing with a static system,
> but others must implement the csound5 changes.  I will continue to
> make an effort to make libtool work in the csound module, but, I have
> to admit, I'm kind of stuck now.
>
> John
>

Date2003-12-15 14:13
Fromramsdell@mitre.org (John D. Ramsdell)
Subject[CSOUND-DEV:3762] Re: Csound GNU build system lessons learned
"Michael Gogins"  writes:

> I suggest the standard pattern as you say; elaborating this, I
> suggest the structure outlined below.

Very nice.

> One major feature of this structure is that the csound/src/csound
> directory contains all the original Csound sources and does NOT
> contain any projects with external dependencies (no third party
> libraries such as FLTK or the VST SDK).

I totally agree.

> csound
>     src
>         csound // traditional csound slightly reorganized, no external dependencies

In order to make csound-config work properly, csound/src/csound should
contain both csound-config.in and the headers that are installed,
i.e., the ones installed into the directory /usr/include/csound by
default.  With this organization, clients of the csound API include
, and the use of the --inplace option of
csound-config will do the right thing.

> If we can't get libtool to build Windows DLLs, then we should drop
> libtool and just use custom rules in the Makefile.am's.

Correct, but remember, I'm the only who has been looking at this
problem.  I've never claimed to be a Windows expert.  Currently, the
DLL generation problem seems to be that libtool cannot handle -lwinmm,
which is needed for MIDI support.  There is something funky about
Cygwin's version of winmm.  I am confident I could generate a DLL if I
didn't have to link with winmm.

> As for FLTK and tabbed panels, CsoundVST has tabbed panels, so I'm
> not sure what you're talking about.

I guess I have to read the FLTK documentation yet again.  The downside
of wxWindows is it is a heavy weight solution, so if I can, and it
doesn't take too much effort, I'd like switch to FLTK.

John

Date2003-12-15 15:00
Fromramsdell@mitre.org (John D. Ramsdell)
Subject[CSOUND-DEV:3764] DLLs on Cygwin
Here is the error message generated when attempting to build a csound
DLL on Cygwin.  The problem seems to be the linker path does not have
real file for library -lwinmm.

John

Making all in csound
make[1]: Entering directory `/home/Administrator/src/csound-4.23.0/shared/csound'
make  all-am
make[2]: Entering directory `/home/Administrator/src/csound-4.23.0/shared/csound'
/bin/bash ../libtool --mode=link g++ -fno-exceptions -fno-rtti -g -O2 -Wall   -o libcsound.la -rpath /usr/local/lib -version-info 0:0:0 -no-undefined libcsound_la-main.lo libcsound_la-argdecode.lo libcsound_la-musmon.lo libcsound_la-otran.lo libcsound_la-oload.lo libcsound_la-rdorch.lo libcsound_la-express.lo libcsound_la-rdscor.lo libcsound_la-linevent.lo libcsound_la-cscore.lo libcsound_la-cscorfns.lo libcsound_la-insert.lo libcsound_la-entry1.lo libcsound_la-entry2.lo libcsound_la-aops.lo libcsound_la-midiops.lo libcsound_la-midirecv.lo libcsound_la-fgens.lo libcsound_la-ugens1.lo libcsound_la-ugens2.lo libcsound_la-ugens3.lo libcsound_la-ugens4.lo libcsound_la-ugens5.lo libcsound_la-ugens6.lo libcsound_la-ugens7.lo libcsound_la-ugens8.lo libcsound_la-ugens9.lo libcsound_la-spectra.lo libcsound_la-disprep.lo libcsound_la-window.lo libcsound_la-winascii.lo libcsound_la-hetro.lo libcsou
 nd_la-lpanal.lo libcsound_la-lptrkfns.lo libcsound_la-pvanal.lo libcsound_la-pvoc.lo libc!
 sound_la-fft.lo libcsound_la-dsputil.lo libcsound_la-sndinfo.lo libcsound_la-sfheader.lo libcsound_la-soundin.lo libcsound_la-soundio.lo libcsound_la-ulaw.lo libcsound_la-aiff.lo libcsound_la-wave.lo libcsound_la-ieee80.lo libcsound_la-filopen.lo libcsound_la-memalloc.lo libcsound_la-memfiles.lo libcsound_la-auxfd.lo libcsound_la-windin.lo libcsound_la-dumpf.lo libcsound_la-scot.lo libcsound_la-scsort.lo libcsound_la-scxtract.lo libcsound_la-sread.lo libcsound_la-sort.lo libcsound_la-extract.lo libcsound_la-twarp.lo libcsound_la-swrite.lo libcsound_la-butter.lo libcsound_la-grain.lo libcsound_la-vdelay.lo libcsound_la-cmath.lo libcsound_la-follow.lo libcsound_la-cvanal.lo libcsound_la-grain4.lo libcsound_la-pvinterp.lo libcsound_la-pvread.lo libcsound_la-sndwarp.lo libcsound_la-vpvoc.lo libcsound_la-hrtferX.lo libcsound_la-winEPS.lo libcsound_la-nlfilt.lo libcsound_la-opcode.lo libcsoun
 d_la-ugrw1.lo libcsound_la-ugrw2.lo libcsound_la-ugensa.lo libcsound_la-cross2.lo libcsou!
 nd_la-dam.lo libcsound_la-midiout.lo libcsound_la-midiops2.lo !
 libcsoun
d_la-midisend.lo libcsound_la-wavegde.lo libcsound_la-filter.lo libcsound_la-complex.lo libcsound_la-repluck.lo libcsound_la-pluck.lo libcsound_la-physutil.lo libcsound_la-physmod.lo libcsound_la-modal4.lo libcsound_la-shaker.lo libcsound_la-fm4op.lo libcsound_la-diskin.lo libcsound_la-pvadd.lo libcsound_la-moog1.lo libcsound_la-singwave.lo libcsound_la-mandolin.lo libcsound_la-space.lo libcsound_la-locsig.lo libcsound_la-dcblockr.lo libcsound_la-pvocext.lo libcsound_la-flanger.lo libcsound_la-aifc.lo libcsound_la-lowpassr.lo libcsound_la-uggab.lo libcsound_la-biquad.lo libcsound_la-one_file.lo libcsound_la-schedule.lo libcsound_la-midiops3.lo libcsound_la-pitch.lo libcsound_la-getstring.lo libcsound_la-ugsc.lo libcsound_la-fout.lo libcsound_la-sndinfUG.lo libcsound_la-pvlook.lo libcsound_la-scansyn.lo libcsound_la-sfont.lo libcsound_la-vbap.lo libcsound_la-vbap_four.lo libcsound_la-vbap
 _eight.lo libcsound_la-vbap_sixteen.lo libcsound_la-vbap_zak.lo libcsound_la-control.lo l!
 ibcsound_la-bowedbar.lo libcsound_la-phisem.lo libcsound_la-sdif.lo libcsound_la-sdif-mem.lo libcsound_la-babo.lo libcsound_la-ugmoss.lo libcsound_la-bbcut.lo libcsound_la-spat3d.lo libcsound_la-pvxanal.lo libcsound_la-mxfft.lo libcsound_la-pvsanal.lo libcsound_la-pstream.lo libcsound_la-pvfileio.lo libcsound_la-oscbnk.lo libcsound_la-scansynx.lo libcsound_la-oscils.lo libcsound_la-wave-terrain.lo libcsound_la-dnoise.lo libcsound_la-dnfft.lo libcsound_la-mididevice.lo libcsound_la-clfilt.lo libcsound_la-midiinterop.lo libcsound_la-csound.lo libcsound_la-load_opcodes.lo libcsound_la-namedins.lo libcsound_la-cmsg.lo rtwin32.lo    -lwinmm 
rm -fr .libs/libcsound.la .libs/libcsound.* .libs/libcsound.*

*** Warning: linker path does not have real file for library -lwinmm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libwinmm but no candidates were found. (...for file magic test)
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
ar cru .libs/libcsound.a  libcsound_la-main.o libcsound_la-argdecode.o libcsound_la-musmon.o libcsound_la-otran.o libcsound_la-oload.o libcsound_la-rdorch.o libcsound_la-express.o libcsound_la-rdscor.o libcsound_la-linevent.o libcsound_la-cscore.o libcsound_la-cscorfns.o libcsound_la-insert.o libcsound_la-entry1.o libcsound_la-entry2.o libcsound_la-aops.o libcsound_la-midiops.o libcsound_la-midirecv.o libcsound_la-fgens.o libcsound_la-ugens1.o libcsound_la-ugens2.o libcsound_la-ugens3.o libcsound_la-ugens4.o libcsound_la-ugens5.o libcsound_la-ugens6.o libcsound_la-ugens7.o libcsound_la-ugens8.o libcsound_la-ugens9.o libcsound_la-spectra.o libcsound_la-disprep.o libcsound_la-window.o libcsound_la-winascii.o libcsound_la-hetro.o libcsound_la-lpanal.o libcsound_la-lptrkfns.o libcsound_la-pvanal.o libcsound_la-pvoc.o libcsound_la-fft.o libcsound_la-dsputil.o libcsound_la-sndinfo.o libcsound_
 la-sfheader.o libcsound_la-soundin.o libcsound_la-soundio.o libcsound_la-ulaw.o libcsound!
 _la-aiff.o libcsound_la-wave.o libcsound_la-ieee80.o libcsound_la-filopen.o libcsound_la-memalloc.o libcsound_la-memfiles.o libcsound_la-auxfd.o libcsound_la-windin.o libcsound_la-dumpf.o libcsound_la-scot.o libcsound_la-scsort.o libcsound_la-scxtract.o libcsound_la-sread.o libcsound_la-sort.o libcsound_la-extract.o libcsound_la-twarp.o libcsound_la-swrite.o libcsound_la-butter.o libcsound_la-grain.o libcsound_la-vdelay.o libcsound_la-cmath.o libcsound_la-follow.o libcsound_la-cvanal.o libcsound_la-grain4.o libcsound_la-pvinterp.o libcsound_la-pvread.o libcsound_la-sndwarp.o libcsound_la-vpvoc.o libcsound_la-hrtferX.o libcsound_la-winEPS.o libcsound_la-nlfilt.o libcsound_la-opcode.o libcsound_la-ugrw1.o libcsound_la-ugrw2.o libcsound_la-ugensa.o libcsound_la-cross2.o libcsound_la-dam.o libcsound_la-midiout.o libcsound_la-midiops2.o libcsound_la-midisend.o libcsound_la-wavegde.o libcsoun
 d_la-filter.o libcsound_la-complex.o libcsound_la-repluck.o libcsound_la-pluck.o libcsoun!
 d_la-physutil.o libcsound_la-physmod.o libcsound_la-modal4.o l!
 ibcsound
_la-shaker.o libcsound_la-fm4op.o libcsound_la-diskin.o libcsound_la-pvadd.o libcsound_la-moog1.o libcsound_la-singwave.o libcsound_la-mandolin.o libcsound_la-space.o libcsound_la-locsig.o libcsound_la-dcblockr.o libcsound_la-pvocext.o libcsound_la-flanger.o libcsound_la-aifc.o libcsound_la-lowpassr.o libcsound_la-uggab.o libcsound_la-biquad.o libcsound_la-one_file.o libcsound_la-schedule.o libcsound_la-midiops3.o libcsound_la-pitch.o libcsound_la-getstring.o libcsound_la-ugsc.o libcsound_la-fout.o libcsound_la-sndinfUG.o libcsound_la-pvlook.o libcsound_la-scansyn.o libcsound_la-sfont.o libcsound_la-vbap.o libcsound_la-vbap_four.o libcsound_la-vbap_eight.o libcsound_la-vbap_sixteen.o libcsound_la-vbap_zak.o libcsound_la-control.o libcsound_la-bowedbar.o libcsound_la-phisem.o libcsound_la-sdif.o libcsound_la-sdif-mem.o libcsound_la-babo.o libcsound_la-ugmoss.o libcsound_la-bbcut.o libcsou
 nd_la-spat3d.o libcsound_la-pvxanal.o libcsound_la-mxfft.o libcsound_la-pvsanal.o libcsou!
 nd_la-pstream.o libcsound_la-pvfileio.o libcsound_la-oscbnk.o libcsound_la-scansynx.o libcsound_la-oscils.o libcsound_la-wave-terrain.o libcsound_la-dnoise.o libcsound_la-dnfft.o libcsound_la-mididevice.o libcsound_la-clfilt.o libcsound_la-midiinterop.o libcsound_la-csound.o libcsound_la-load_opcodes.o libcsound_la-namedins.o libcsound_la-cmsg.o rtwin32.o 
ranlib .libs/libcsound.a
creating libcsound.la
(cd .libs && rm -f libcsound.la && ln -s ../libcsound.la libcsound.la)
/bin/bash ../libtool --mode=link gcc  -g -O2 -Wall -falign-loops=4 -falign-jumps=4 -ffast-math -fomit-frame-pointer -finline-functions -funroll-loops   -o csound.exe  ccsound.o libcsound.la -lwinmm 
gcc -g -O2 -Wall -falign-loops=4 -falign-jumps=4 -ffast-math -fomit-frame-pointer -finline-functions -funroll-loops -o csound.exe ccsound.o  ./.libs/libcsound.a -lwinmm
make[2]: Leaving directory `/home/Administrator/src/csound-4.23.0/shared/csound'
make[1]: Leaving directory `/home/Administrator/src/csound-4.23.0/shared/csound'