At the moment, utool builds really prettily on Linux:
Most of the material is put into libdomgraph.so, and
the utool executable is linked dynamically against
libdomgraph.so.
Under Windows, we do build a libdomgraph.dll, but then
all object files are linked together statically _again_
to build utool.exe. Then when the Swig/Java integration
is built, all object files are linked together
statically _again_ to build DomgraphSwig.dll.
This is not as nice as it could be. We should link
utool.exe and DomgraphSwig.dll dynamically against the
DLL just like under Linux.
The main thing we'd need to do for this is to create an
import library libdomgraph.lib when we build
libdomgraph.dll. Then we could tell the linker to link
utool and DomgraphSwig.dll against libdomgraph.lib, and
everything would be fine.
The Microsoft linker will automatically generate
libdomgraph.lib if we give it a libdomgraph.def
declaration file, in which we list all exported
symbols. The thing that needs to be done is either (a)
to find a way to extract all symbols to make them
exported, or (b) to create a *.def file manually, in
such a way that it will stay up-to-date when we change
stuff in libdomgraph. Possibly there's an option (c):
the MSVC compiler seems to support a "declspec"
notation that you can put in front of methods (and
#define it to the empty string for non-Windows
compilers), and that will tell the compiler that this
symbol should be exported.