Re: Merge cpplib and front end hashtables, part 1

[Fergus Henderson <fjh at cs dot mu dot oz dot au>]

On 18-May-2001, Zack Weinberg <zackw@Stanford.EDU> wrote:
> On Fri, May 18, 2001 at 05:58:03AM +1000, Fergus Henderson wrote:
> > On 17-May-2001, Zack Weinberg <zackw@Stanford.EDU> wrote:
> > > On Fri, May 18, 2001 at 02:16:05AM +1000, Fergus Henderson wrote:
> > > > On 17-May-2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:
> > > > > So we need a way to specify it on a per-file basis, presumably in the
> > > > > file itself.
> > > > 
> > > > Here I disagree on two counts.
> > > > 
> > > > Firstly, I think in most cases it would be more convenient to
> > > > specify it on a per-directory basis rather than a per-file basis.
> > > 
> > > What sort of interface do you have in mind for this?
> > 
> > Oh, I was thinking along the lines of a command-line option;
> > perhaps a variant of `-I' that also specifies the encoding.
> 
> This seems rather fragile to me.  Should users have to know what
> encoding a directory of headers, which they did not necessarily
> write, is in in order to use those headers successfully?

No.  With the appropriate foo-config script, the users can just put

	FOO_CFLAGS = `foo-config --cflags`
	BAR_CFLAGS = `bar-config --cflags`

	CFLAGS = $(FOO_CFLAGS) $(BAR_CFLAGS) ...

in their Makefile.  (Or use GNU Make and := instead of =,
or run foo-config from your configure script, etc.)

> > > Also, I don't think per-directory is fine grained enough.  Suppose you
> > > have three third-party libraries all of which install headers in
> > > /usr/include, written in three different countries, and all the
> > > headers have comments in the native language of the country of origin.
> > > I don't think that's at all far-fetched.
> > 
> > Well, IMHO third-party libraries shouldn't be installing their headers in
> > /usr/include.  For one thing, this prevents having multiple versions
> > of each third-party library installed simultaneously.
> > Instead, each third-party library should install its headers in a
> > version-specific and hence package-specific directory.
> 
> This is debatable - as a library user I wouldn't want to have to
> change all my #include lines just because the sysadmin bumped the
> library revisions on me.

Doing that would be terrible, I agree.
Instead, you should just change the command-line arguments that you
pass to gcc to specify the right directory.  And even that can be done
via the foo-config script, as shown above, so all you need to change is
your PATH environment variable (and depending on where the sysadmin
installs the bin/ directory stuff, maybe not even that).

> Also, development files for a library aren't
> just the headers; for shared libraries, you need the libfoo.so link as
> well, which can have no version number, and has to live in /usr/lib or
> it won't work.

If you use the appropriate -rpath (or equivalent) options then it doesn't
have to live in /usr/lib.  (This too can be done via foo-config, so
the user doesn't need to know about it, or worry about the platform-dependent
syntax for the -rpath option.)

If it does live in /usr/lib, then it ought to have a version number.

> Common practice here seems to be that you can install multiple
> versions of the runtime library, but just one version of the
> development files (headers, libfoo.so, libfoo.a, etc).

Yeah, well, common practice often has a lot of room for improvement ;-)

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.