Re: On the cost of libraries

[Maciej Stachowiak <mjs noisehavoc org>]

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).

> > 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. :-)

 - Maciej