On Friday 14 September 2007 12:44:25 Anthony Kozar wrote:
> There are quite a few functions beginning with "csound" that are not public
> API functions.  They are more like "internal APIs" -- functions that
> someone expected would be called by other parts of the Csound engine.  Some
> of them may also have been candidates at one time for inclusion in the
> public API. (And a few were public but then privatized for various
> reasons).

Good. So there should be no reason to suspect that public functions are not 
marked as PUBLIC? Another note is that I see no data marked as PUBLIC... 
normally this is good, but since I don't know the csound API I don't know if 
some variable ought to be accessible to clients.

>
> I think Istvan named a lot of functions this way and he tried to make sure
> most other functions were declared static.  I have imitated this practice
> myself.

This is really a better practice. What I see sometimes that may be an 
alternative is creating PUBLIC and PRIVATE #defines, and then appropriately 
mark _every_ function in the source. Of course, usually this is done when 
starting the project, not decades afterwards, since it's a pain to mark them 
when you have a large API.

>
> I don't think that there are currently any symbols not marked PUBLIC in the
> code that should be.  I agree that libraries should be built so that only
> the PUBLIC functions are exported.  I have had warnings while building
> Cscore programs on OS X because the framework library is improperly
> exporting private symbols.

Ok, so I might be doing this for Debian. In the meanwhile, attached is a patch 
that will build exposing only PUBLIC functions when building under linux and 
creating a shared library. The problem is that the command 
option -fvisibility is only present from gcc 4.0 and upwards, so I had to add 
a configure check for it. This means that there will be no difference for 
people compiling with gcc < 4.0.

-- 

	Felipe Sateler