Re: RFC: Building a Shared Library (take 2)

[Norman Gray]

Alexandre,

On Thu, 31 Jul 2003, Alexandre Duret-Lutz wrote:

>  Norman> You don't need to know anything about the structure of `.la' or `.lo'
>  Norman> files (and they are subject to change), but it is these files that
>  Norman> libtool and automake use to coordinate the dependencies in a package,
>  Norman> and it is these which you should use to express those dependencies.
>  Norman> In other words, the existence of the libtool libraries and objects is
>  Norman> part of the automake API; the content is not.
> 
> Hmmm, I'd rather not mention the API outside its section, or
> we'll end up doing it everywhere.

A good point!

> Everything which is documented is in the API.

This is fine, and a good principle, as long as the converse is also true,
or nearly so.

If some parts of it aren't explicit, however -- if we don't have
statements like `thou shalt use .lo and .la files to express dependencies'
-- then folk will use the source to work out what the API is, or `what
version x.y.z does', and come to some very odd conclusions.  Or, which is
not quite the same thing, come to the correct conclusion but be uncertain
how robust it is (my case, sort of), and so be left with an uncomfortable
feeling that automake is even blacker magic than it really is.

>    You should not assume anything about the structure of `.la' or `.lo'
> files and how libtool constructs them: this is libtool's concern, and
> the last thing one wants is to learn about libtool's guts.  However the
> existence of these files matters, because they are used as targets and
> dependencies in `Makefile's when building libtool libraries.  There are
> situations where you may have to interact with these, for instance when
> setting dependencies for building source files conditionally (*note
> Conditional Libtool Sources::).

Works for me!  I might suggest `...have to refer to these, for
instance when expressing dependencies...'.

>  Norman> Also, note that if you include the declarations for building a shared
>  Norman> library, automake will automatically build the corresponding static
>  Norman> library [this is true, isn't it?]  
> 
> Honestly I don't know.  Perhaps it's true, I guess it is, but
> even tho I wouldn't assume that if libfoo.la exists then
> libfoo.a exists.  Since I've requested libfoo.la, I shall only
> use libfoo.la.  Static linking against libfoo.la can be forced
> using libtool's -static or -all-static options.

It's certainly true with automake 1.7.5 -- I currently depend on it.

It seems a Good Thing, however, because if you're building shared
libraries, you very likely want to build the corresponding static
libraries also, and even if you don't for some reason, there's no real
harm in getting them (though it should be configurable, of course).

Also, if I was using libtool for shared libraries, I'd be nervous of
simultaneously building static libraries either with libtool or the simple
way, in case I accidentally override an automatically-generated rule or
dependency.  Do I use $(OBJEXT) for the libfoo_a_SOURCES dependencies,
or suddenly switch to .lo?  Do I put -static in the libfoo_a_LDFLAGS
variable, or somewhere else?  I could certainly work out the answers to
these questions, but I was, and am, quite relieved that automake magic
meant I didn't have to.

It means there's only one set of dependencies to configure in
configure.ac.  And finally, a principle of least surprise suggests
that it's a virtue, which merely needs blessed by a mention in the
documentation.

> I guess LIBOBJS really needs its own section, but one chore a
> week is enough :)

Quite enough.  Many thanks for this chore -- I'm sure I'm very far
from being the only one who's benefited.

All the best,

Norman


-- 
---------------------------------------------------------------------------
Norman Gray                        http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK     address@hidden