Re: On the cost of libraries

[Owen Taylor <otaylor redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes:

> On 02Sep2001 08:02PM (-0400), Havoc Pennington wrote:
> > 
> > Maciej Stachowiak <mjs noisehavoc org> writes:
> > > On 01Sep2001 03:58PM (-0700), Darin Adler wrote:
> > > > on 9/1/01 3:48 PM, Havoc Pennington at hp redhat com wrote:
> > > > 
> > > > > See GTK - use libtool:
> > > > > 
> > > > > # libtool option to control which symbols are exported
> > > > > # right now, symbols starting with _ are not exported
> > > > > LIBTOOL_EXPORT_OPTIONS='-export-symbols-regex "^[[^_]].*"'
> > > > > AC_SUBST(LIBTOOL_EXPORT_OPTIONS)
> > > > > 
> > > > > We make private symbols start with _, but if you didn't want to do
> > > > > that you can also have a file where you make a list of private
> > > > > symbols. libtool just uses the regexp to generate the file.
> > > > 
> > > > My own personal taste would be to generate the list of symbols to export
> > > > from a simple-minded "parse" of the public headers and make everything else
> > > > private. It seems like it might be straightforward to come up with a way to
> > > > do this that could be reused in various libraries.
> > > > 
> > > 
> > > I really like this idea. 
> > 
> > It sounds fine, the important thing IMO is that your system is
> > inline. That is, you can privatize/deprivatize by changing the source
> > files. The docs experience demonstrates pretty conclusively that to
> > keep things up to date they have to be right next to the code.
> 
> I think Darin's suggestion is that the way to privatize/deprivatize is
> by adding a prototype to a public, installed header, or removing a
> prototype from the public headers. This makes the set of exported
> symbols exactly match the installed headers. (Sometimes libraries have
> helper programs or additional libraries that use private entry points
> - you'd have to include the headers that declare those too).

Well, if you don't mind lots of gtkwidgetP.h type files this works
fine. If my non-exported functions are methods on a widget, I'd really
like them in the main header for the widget... after all, the headers
shouldn't be the primary form of documentation.
 
> > > I like it better than the underscore prefix
> > > convention, especially given the fact that symbols with leading
> > > underscores are in theory reserved to the C implementation.
> > 
> > You could use a different regexp you know. ;-) Not really a
> > fundamental property of this approach.
> 
> I think I also dislike privateness being a naming convention in
> general. Darin's approach sounds much cooler to me, especially if he
> implements it. :-)

The normal approach on windows is something on the order of:

 G_EXTERN void my_function_to_export ();

Rather ugly, but certainly explicit. 

(For the GTK+ libraries, we actually have separately maintained .defs
files to keep track of exports for the Windows port - which is in no
way good, and we need to get away from one way or the other.)

Regards,
                                       Owen