[Clp] how do I generate dll files in the MSVisualStudio?

[Lou Hafer]

Michel,

> I am trying generate dll files of the LibCoinUtils and libClp subprojects
> from MSVisualStudio project [ ... ] How do I achieve this?

	The short answer is `It can be done.' The longer answer will not make 
you happy, however.
	
	The basic problem is that Microsoft requires you to specify the symbols
(methods, variables) that will be exported from the DLL for use by other code.
There are two ways to do this:

  * litter the code with __declspec annotations which are syntax errors
    in any environment except Windows, or
  * generate a .def file which specifies the symbols to export.
  
Generating a .def file for C++ code is not something to do by hand, because you
must use the mangled names for the C++ methods.

	The v9alt project files will allow you to build DLLs for CoinUtils, Osi,
Clp, and DyLP.  DyLP is plain C and has a manually constructed .def file.  The
other three use a PowerShell script to create the .def file during the build.  I
can verify that this works with VS 2008 and Windows 7.  You mention VS 2005.  I
have no plans to back port from VS 2008, so you're on your own there.  Either
upgrade your code environment or do the back port (in which case we'd love it if
you contribute it back to us).  I plan to expand the DLL builds to include Cgl
and Cbc, but I'm in no hurry and have no plans to become the Windows guy.  We
(Coin) need some volunteers, people who actually like to develop in Windows.

	I should mention that if you move up to Clp 1.13 or 1.14, both the v9
and v9alt builds use the DLL-compatible runtime.  I've attached a file that
explains how to use the v9alt builds.

							Lou
	
	
-------------- next part --------------

	How to use the COIN v9alt Visual Studio Solutions

	The basic concept of v9alt matches the current direction in Coin
unix builds: Move away from a monolithic package checkout towards individual
project checkouts that are stitched together for use. As an additional
benefit, you get a much richer set of choices: (static lib, DLL) X (64,
32 bit) X (debug, release) Projects are stitched together with a cascade
of .vsprops files.

	Results are placed in a common location. Static libraries and DLL
export libraries (.lib) go to a lib directory. Executables (.exe) and DLLs
(.dll) are placed in a bin directory. Individual bin and lib directories form
the leaves of a directory tree sorted by configuration.

	v9alt is a work in progress. For 32-bit and 64-bit static libraries,
there are solutions for CoinUtils, Osi, Clp, DyLP, Cgl, and Cbc. DLLs can
be built for CoinUtils, Clp, DyLP, and Osi. DLL builds require PowerShell
in order to run a script that constructs the .def file for the DLL as part
of the build.  Where DLL support is in place, trivial assemblies can be
built by enabling CLR support.

	There is no support for ThirdParty software in v9alt. It may happen
eventually.

	The rest of this post is an explanation of how to use v9alt.

	So far, BuildTools, CoinUtils, Osi, Clp (with OsiClp), DyLP (with
OsiDyLP), Cgl, and Cbc have v9alt solutions. To use them, proceed as follows:

  1) Check out the projects above, *without externals*. Be careful
     with updates, it's easy to let the externals creep back in. For Turtle
     SVN, look for the `Update to revision' menu item.

     Also check out the Data projects you'll want to use: Typically,
     Sample, netlib, and miplib3.

  2) The directory where you checked out all these packages is COIN_ROOT.
     Define COIN_ROOT in your environment. Also define COIN_ROOT_ESCAPED,
     which will be used to get things like D:\Coin\Split into code via
     compile-time defines.

     For example, my setup looks like this:
       D:\Coin\Split\BuildTools
		    \Cbc
		    \Cgl
		    \Clp
		    \CoinUtils
		    \DyLP
		    \Osi
		    \Data\Sample
			 \netlib
			 \miplib3

     COIN_ROOT is D:\Coin\Split
     COIN_ROOT_ESCAPED is D:\\Coin\\Split

  3) Go to ....\MSVisualStudio\v9alt and build each solution, in the
     order Coinutils, Osi, Clp, DyLP, Cgl, Cbc. (There's no need to
     build in BuildTools; v9alt there contains only property and include
     files.) There's probably a good way to script this, but my Windows
     isn't that good yet. The `Batch Build' entry in the VS Build menu is
     the efficient way to build however many configurations you want.

Results are sorted as follows:

  %COIN_ROOT%\{Win32,x64}\{Debug,Release}\{bin,lib}

The solution and project files use macros to find the right places. Most of
this is defined in the .vsprops files. At first glance, you'll see little when
you look at property pages, but check the inherited values.

	One drawback is that you need to change the Path environment
variable to find the correct bin directory, for executables and DLLs. There
are techniques to make this fairly transparent on unix systems. Presumably
there's an equivalent way on Windows. I don't know what it is.

	A quick word about DLL builds: The basic problem is that it's
necessary to supply a list of exported symbols in order to build the export
library for the DLL. There are two ways to do this: decorate the symbols
with __declspec, or list the symbols in a .def file. COIN software runs
on many platforms, so it's unattractive to litter the code with something
(__declspec) that's just a syntax error everywhere except Windows. The
solution adopted here is to run a PowerShell script off the prelink
hook. This script uses dumpbin to dump the symbols from the relevant .obj
files, filters them, and writes the .def file for use in the link. This
turns out to be reasonably fast and has the advantage that new methods
are automatically exported. There's lots of room for improvement. Only
CoinUtils and Clp are ready to build 64-bit DLLs. As another example,
the set of object files is hardcoded into several of the scripts. There
must be some way to pass this in from Visual Studio.

	V9alt is very much a work in progress. I'll be working on it over
the next few months, gradually filling out the full set of configurations
for all solutions, alternating with vacations on unix  :-). At some point,
I'll update to VS2010 and all future work will proceed there.

	Feedback from people who have real experience developing with VS
would be much appreciated.  Contributions even more so.

							Lou Hafer
							lou at cs.sfu.ca