Your suggestions about graph window drivers and other drivers are OK with
me. 

About Windows DLLs, I wish to avoid the problem of declaring funtions for
import with one macro, and for export with another macro. That is why I
prefer that opcodes use the function pointer interface to Csound that is
already present in the OPDS header.  In that case the Csound library need
only export, and need not import, its public functions. The PUBLIC macro
currently does this. 

The PUBLIC macro should be applied to all API functions (it hasn't been,
yet, because I am probably the only one who consistently builds Csound as a
Windows DLL, and I exclusively use a function pointer interface to Csound
that I get from CsoundVST).

For a static library, or a UNIX/Linux library, these considerations do not
matter.

Original Message:
-----------------
From:  ramsdell@mitre.org (John D. Ramsdell)
Date: 20 Nov 2003 08:37:23 -0500
To: csound-dev@eartha.mills.edu
Subject: [CSOUND-DEV:3437] What should configure.ac do?


"Michael Gogins"  writes:

> I haven't had time to do anything with csound5 yet - sorry! I really
> will!

Perhaps this is a good thing.  Perhaps I was pursuing the wrong path
by asking John what he intended to do in the existing configure.in.
The question that should be answered before Michael works on csound5
configuration is what should configure.ac do to serve needs of the
developer community.  

I propose it should do the following:

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-fltk=no.
Also, define WINDOWS and HAVE_FLTK.

For every platform that does not support FLTK or when --with-fltk=no,
but does support X11, use winX11.o as the graphing object, and define
WINDOWS and HAVE_LIB_X11.

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

Finally, based on the operating system, select the appropriate
real-time audio object files, unless --with-rtaudio=no.  Also, define
RTAUDIO and a variable identifying the operating system.  I'm assuming
the host's architecture is never relevant, only its operating system.

Note that when HAVE_FLTK is defined, csound.c should use specify an
FLTK graphing routines by default, and when HAVE_LIB_X11 is true, it
should specify the X11 graphing routines by default.

> The windows DLL stuff would be practically essential. Both the Csound API
> itself (Csound as a library), and plugin opcodes, should be DLLs. I think
> you should enable the macro.

Yes, but does csound.c have to export items with
`__declspec(dllexport)' and import them with `__declspec(dllimport)'?
I admit I know little about Windows libraries.

John


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