dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Feb 16, 2006 at 06:42:53PM +0100, Johan Jansson wrote:
> On Thu, Feb 16, 2006 at 06:11:00PM +0100, Garth N. Wells wrote:
> > OK, I didn't know if we would need to set a new variable, or if
> > DOLFIN_LTLIBS could just be redfined. I see that you've added a new
> > variable.
> 
> The variable name DOLFIN_LTLIBOBJS is arbitrary, it could be
> anything. I just changed the name to clarify what it contains. I think
> much of the confusion about libtool comes from the various types: .lo,
> .la, .lai, .lax etc. so I'm just trying to keep it straight. The
> libdolfin_la_* and lib_LTLIBRARIES variable names are reserved though
> and mean something.
> 
> > 
> > > With the change to linking directly against the library object files,
> > > the individual libraries (libdolfin-la, libdolfin-stokes etc.) are
> > > redundant and I think just confusing, so I will remove them if you
> > > agree with this. In the terminology of libtool, every object file is a
> > > library anyway. We can still keep the structure, just that it won't
> > > show up in the libraries.
> > > 
> > 
> > I see the concept "convenience" libraries a lot with libtool. We could
> > still make all the individual libraries, but only install libdolfin.a.
> > Is there an advantage in doing this?
> > 
> > Garth
> 
> I don't think there's an advantage in this case. This is what the
> libtool manual says about convenience libraries:
> 
> http://www.gnu.org/software/libtool/manual.html#Linking-libraries
> 
> "sometimes it is desirable to create a static archive that can never
> be shared.  The most frequent case is when you have a set of object
> files that you use to build several different programs.  You can
> create a "convenience library" out of those objects, and link programs
> with the library, instead of listing all object files for every
> program.  This technique is often used to overcome GNU automake's lack
> of support for linking object files built from sources in other
> directories, because it supports linking with libraries from other
> directories.  This limitation applies to GNU automake up to release
> 1.4; newer releases should support sources in other directories."
> 
> I think this is essentially what we were trying to do with the .la
> libraries in every individual directory. But it just seems to
> introduce extra difficulties; we have to worry about linking those
> libraries in correctly.
> 
> I'll go ahead with removing the individual libraries, I think it's
> just as important to remove complexity sometimes as it is to add new
> things.

Very good point.

/Anders