[lmi] Building with shared-library attributes

[Greg Chicares]

It may be useful to explain the purpose of recent changes committed, e.g.,
  20051220T0046Z
  20051222T1359Z
  20051231T1659Z

At one time, all the dll export and import decorations were correct, and
the whole project built correctly with both gcc and borland, using import
libraries. That was over a year ago. Binaries that used dlls had their own
build directory; objects for static linking used a different directory.

Since then, I had to drop support for borland, because it's fallen far
behind the times, for instance wrt boost:
  
http://groups.google.com/group/borland.public.cppbuilder.non-technical/msg/9dde2920eea5d7b0
leaving me with no compiler other than gcc that builds lmi. That's not a
good situation at all, because it becomes too easy to write nonportable
code--which is one good reason to try to support msvc, as we've discussed
at various times. I still try building unit tests with borland and como,
both of which (especially como) have helped prevent such portability
problems. (Working out the problems with como is another approach that
might be advantageous: IIRC, it's just a matter of libxml2 compatibility.)

Then I rewrote all the makefiles to use a single directory for static and
dll builds: that saves build time, and it works with gcc, which can link
directly to a dll without using any import library. As a consequence, the
dll import and export decorations became irrelevant and were no longer
maintained, and what is not maintained quickly becomes incorrect.

At that point, I might have removed the decorations completely. I did not,
because that may make it harder to support another msw compiler, and also
because significant advantages are claimed for the very similar visibility
attributes used by elf. Instead, I updated the decorations so that
  make lmi_wx_shared.exe build_type=so_test USE_SO_ATTRIBUTES=1
works with MinGW gcc-3.4.2 .

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

  product_files$(EXEEXT)
This is a monstrosity. Product files should be converted to xml for a
variety of excellent reasons. When that's done, this target will be
removed completely. To pursue a conflicting goal is a waste of time.

  elapsed_time$(EXEEXT)
  generate_passkey$(EXEEXT)
  ihs_crc_comp$(EXEEXT)
These auxiliary tools can always be linked statically. They have little
code in common, so shared libraries would bring little benefit.

  unit tests
There are forty-four programs in this category, and more will be added.
They make it easy to experiment with different implementations, by
shortening the compile-link-test cycle for each isolated feature, so
each should build as quickly as possible. Using shared libraries here
would increase link time dramatically, defeating that purpose. It would
also require making visible interfaces that are deliberately invisible:
that would vitiate the encapsulation afforded by visibility decorations.

  the antediluvian "branch"
This is a semi-distinct body of code on the same physical cvs branch.
It is a cleaner, faster, but less capable implementation of the core
insurance routines than the production "branch". It exists for historical
political reasons. It fails to build today with shared-library decorations
mostly because 'calculate.hpp' slices across a dll boundary; that file I
regard as an essential defect. To make visible the invisible details it
defectively accesses would be worse than a waste of effort: it would just
compound a problem that is best solved by removing that file and cleanly
reimplementing everything it does, which we must do in the next few months
anyway in order to support a command-line version of lmi that will be
required for business reasons.

File 'so_attributes.hpp' differs from the usual implementation, which
would look something like this:

  #if defined BUILD_DLL
  #   define dll_decoration __declspec(dllexport)
  #elif defined USE_DLL
  #   define dll_decoration __declspec(dllimport)
  #else
  #   define dll_decoration
  #endif

in that it adds an extra safety feature. It wraps the whole block in a
conditional (LMI_USE_SO_ATTRIBUTES) that chooses between shared and static
builds, and then requires that either the 'build' or the 'use' macro be
defined for shared builds. This helps reject any doomed attempt to link
the exceptional targets listed above, producing a linker error instead of
a segfault at run time. The production system is to be built only without
defining LMI_USE_SO_ATTRIBUTES.

It is probably possible to use shared-library decorations for autotools
builds nonetheless, if necessary, by prepending a block like this:

  #if defined HAVE_CONFIG_H
  #   define LMI_USE_SO_ATTRIBUTES
  #   if defined DLL_EXPORT
  #       define LMI_BUILD_SO
  #   else  // !defined DLL_EXPORT
  #      define LMI_USE_SO
  #   endif // !defined DLL_EXPORT
  #endif // defined HAVE_CONFIG_H

but that will work only for the main binary, lmi_wx_shared$(EXEEXT).