Steven Yi wrote:

> Regarding CS5 and a release, I think one thing that should be
> addressed is the csound.h file.  I know with Matt's MacCsound, all
> things necessary for either a plugin or host is contained in csound.h.
>  I think this would be ideal.  Currently there's a split between
> csound.h and csoundCore.h.  Any thoughts?

The separate files are there to provide access to the interfaces needed
(but not more) for a particular type of application (hosts, plugins, and
internals), while hiding as much of anything else as possible to reduce
namespace pollution and prevent host applications and plugins from using
"private" internal types and functions that change frequently in an
incompatible way. Also, many of the API functions only make sense (and in
fact only work correctly) in plugins, but not in host applications;
examples include those that take a pointer to an opcode data structure
as argument, or those that may possibly call longjmp.

So, there are these header files, of which you should always include
exactly one:

csound.h:     for host applications

This interface is the most limited, it allows access only to the standard
API functions for creating a Csound instance, compiling, performing, registering
a message callback, etc. It also declares CSOUND as an incomplete "opaque"
type of which the contents cannot be accessed.
Of course, not being able to use any internals also means not being broken
by changes to the various structures, and there is significantly less amount
of namespace pollution from all the macros and typedefs in the other header
files.

csdl.h:       for plugins

This interface makes it possible to use function pointers as well as a limited
set of "public" data in the CSOUND structure, and also all the structures and
macros that are expected to be used by a plugin library.
It does not, however, declare function prototypes, and some internal data types
are still hidden.

csoundCore.h: for Csound internals

Allows full access to everything. You should never include this header in
anything other than the files in Engine/, OOps/, Top/, and non-plugin files
in InOut/.

> Also, at the moment with the current SConstruct files, all .h files
> seem to be installed into /usr/local/include/csound which seems a bit
> overkill.  I think it'd be great if we could start putting together a
> separate opcode SDK package that has a very simple plugin opcode with
> Makefile--which I think is plenty enough for an opcode plugin--that
> can compile using just what will be installed, to help encourse
> external opcode building.

I will change SConstruct to install only those files from H/ that are
needed by csound.h and csdl.h. However, I am not familiar with CsoundVST,
so all headers of CsoundVST will still be installed.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net