← Back to team overview

dolfin team mailing list archive

Re: Version 0.6.0?

 

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.


Sure, the names are arbitrary. I didn't know if libdolfin_la_LIBADD and libdolfin_la_DEPENDENCIES required the same list of files, making one variable is enough, or if they needed different lists (one .lo files, the other .la files, for example).

The build system works fine now with Cywgin. Static executables are built (even when not using --disbale-shared), so I think libtool figures out that it's best to use static libraries under Cygwin.

Garth


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.

  Johan

_______________________________________________
DOLFIN-dev mailing list
DOLFIN-dev@xxxxxxxxxx
http://www.fenics.org/cgi-bin/mailman/listinfo/dolfin-dev




References