I was not aware of the rationale for removing the pointers, so I assumed that the rationale was to prevent opcodes from calling Compile or Perform, which seemed silly to me since clients of the API are not always opcodes.

It still seems dangerous to me to have so many forms of the API floating around. In the long run, I would prefer that Csound and its API be a C++ class that is always dynamically linked. That would preserve the simplicity of the API that I am aiming for while, as you intend, avoiding redundant linkage.

In the meantime, if it is too much trouble to link the utilities dynamically, I have no objection to removing the pointers again.

Regards,
Mike

----- Original Message ----- 
From: "Istvan Varga" 
To: 
Sent: Saturday, July 16, 2005 4:30 PM
Subject: [Cs-dev] oload.c


>I noticed that the function pointers for Compile and Perform have been
> changed back from NULL to csoundCompile and csoundPerform. Are these
> actually used somewhere (I mean, through the pointers in ENVIRON) ?
> While having the actual function pointers instead of NULL does not
> break anything, it does result in huge and bloated utility executables
> (because all will include the entire opcode library on which csoundCompile
> depends) and it also takes an annoyingly long time to re-link all the
> utilities if any of the libcsound source files is changed.
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> In the meantime, if it is too much trouble to link the utilities dynamically,
 > I have no objection to removing the pointers again.

It is easy to link the utilities dynamically (just add dynamicCsoundLibrary=1
to the scons options), although on Linux (and possibly OS X) it requires
setting LD_LIBRARY_PATH so that the libcsound.so file is actually found by
the system. Also on Linux a dynamically linked Csound runs about 5% slower.
However, neither of the above are a problem on Win32: it is enough to have
csound.dll in the same directory as csound.exe, CsoundVST.exe, or any other
executables, and there is apparently no slowdown either.
Indeed, in my just announced Win32 release I did use a dynamic Csound library
which is largely responsible for having a package size of only 7 MB, even
though full source code, HTML manual, and both single and double precision
binaries are included.

In any case, a released version of Csound should come with the Compile and
Perform pointers enabled, however, it is convenient to have the pointers
replaced with NULL for development as the reduction in executable sizes and
linking time does make a difference on old computers (such as the one I have).


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net