Re: [lmi] Building with shared-library attributes

[Vadim Zeitlin]

On Sun, 01 Jan 2006 16:29:49 +0000 Greg Chicares <address@hidden> wrote:

GC> Then I rewrote all the makefiles to use a single directory for static and
GC> dll builds: that saves build time, and it works with gcc, which can link
GC> directly to a dll without using any import library.

 Unfortunately AFAIK this is the only Windows compiler which can do this
and if we ever want to support another one, we really shouldn't rely on
this.

GC> It is not my intention to make everything work with shared-library
GC> decorations:

 I'd like to object to this: IMHO it's very confusing to use both static
and shared libraries in the same build. Again, this might work without
problems with gcc and its auto import feature and also because all code is
relocatable under Windows but it wouldn't work with another Windows
compiler or on another architecture where shared libraries have to be built
with special options to generate relocatable code. So I think it would be
much better to always link everything statically or dynamically but don't
mix the two as this could easily hide the problems which would manifest
itself in any other build configuration.

GC>   unit tests
GC> There are forty-four programs in this category, and more will be added.
GC> They make it easy to experiment with different implementations, by
GC> shortening the compile-link-test cycle for each isolated feature, so
GC> each should build as quickly as possible. Using shared libraries here
GC> would increase link time dramatically,

 Sorry, this is exactly contrary to my experience. Linking statically is
usually quite slow because the linker needs to extract the required
functions from the static library and create a usually huge final
executable. Linking against a DLL is much faster and, even better, you can
avoid relinking entirely if you've changed just the library and not the
test itself.

 Also, 44 unit tests lunk statically can consume quite a lot of disk space
and space saving allowed by using the shared libraries can be useful in
this situation.

GC> File 'so_attributes.hpp' differs from the usual implementation, which
GC> would look something like this:
GC> 
GC>   #if defined BUILD_DLL
GC>   #   define dll_decoration __declspec(dllexport)
GC>   #elif defined USE_DLL
GC>   #   define dll_decoration __declspec(dllimport)
GC>   #else
GC>   #   define dll_decoration
GC>   #endif
GC> 
GC> in that it adds an extra safety feature. It wraps the whole block in a
GC> conditional (LMI_USE_SO_ATTRIBUTES) that chooses between shared and static
GC> builds,
...
GC> The production system is to be built only without defining
GC> LMI_USE_SO_ATTRIBUTES.

 Ok, this is an important thing to know. I still am not sure if this is a
final decision or subject to change in the future?

 Thanks,
VZ