[Coin-discuss] Alternate build strategy for Visual Studio

[Lou Hafer]

Folks,

	I've put together a new strategy for building Coin with MS Visual
Studio. The result is committed in trunk in MSVisualStudio/v9alt. The basic
concept 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 four
configurations, (64, 32 bit) X (debug, release); useful for developers.
Projects are stitched together with a cascade of .vsprops files. All results
(.lib and .exe) are stashed in a common location (sorted by configuration).

	The rest of this post is an explanation of how to use it. If you don't
build with Visual Studio, you can quit reading now.

	So far, BuildTools, CoinUtils, Osi, Clp (with OsiClp), DyLP (with
OsiDyLP), Cgl, and Cbc have the new solution and project files. To use them,
proceed as follows:

  1) Check out the projects above, *without externals* (and be careful
     with updates, it's easy to let the externals creep back in).

  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

  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. (Skip BuildTools, it's just data
     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.

	I look at this as an experiment, and I'll be working on it over the
next few months, alternating with vacations on unix  :-). Feedback from people
who have real experience developing with VS would be much appreciated.
Contributions even more so. I expect this effort looks painfully naive to an
experienced VS user.

	OsiCbc isn't there yet (sorry, Matt G.  :-). It's on my list for next
week. I'm having trouble seeing how to fit DLLs into this. A DLL is located
using Path (like an executable), but the .lib wrapper that's used to do
implicit linking of a DLL is (presumably) located like a regular library. I
need to figure out how to get the two products to different places (assuming
that doesn't break some Microsoft assumption of how the world should work).
There is the distinct possibility that things will break with the free download
version of VS (in particular, 64-bit builds may be unavailable or fail).

							Lou