[BuildTools] Putting COIN projects `elsewhere'

[Lou Hafer]

BuildToolers,

	Over in coin-discuss, May 9th, there's a post from Dean Kassmann asking
how to go about building *all* OSI interfaces. In particular, the OSI interfaces 
for COIN projects (Cbc, Symphony) that aren't part of the OSI project bundle. 
One solution is to treat them as `third-party' software. After a bit of thought,
it seemed to me that COIN_HAS_PROJECT and COIN_HAS_USER_LIB together might do 
the trick, using the following construction:

  COIN_HAS_PROJECT(Foo)
  if test $m4_tolower(coin_has_foo) != skipping && \
     test $m4_tolower(coin_has_foo) = unavailable ; then
    AC_COIN_HAS_USER_LIBRARY([Foo],[FOO],[foo.hpp])
  fi

With some minor tweaks to coin.m4 and OsiFoo/Makefile.am, this actually does the
job for projects with simple structure (Cbc, for example) where all source and
include files are in one subdirectory.  But for projects with complex structure
(Symphony, for example) there's big trouble down in OsiFoo/Makefile.am.

	In effect, if a project is incorporated into the Osi build (by fiddling
Externals, using links, or similar), the expectation is that the build will
complete by finding include files in the appropriate places in the source tree
for Foo.  OsiFoo/Makefile.am deals with this.  But for `third-party' stuff, the
expectation is that all necessary include files will be collected in some
installation include directory.  The two are not compatible.  Compare, for
example, OsiSym/Makefile.am and OsiGlpk/Makefile.am.  I've just been playing
with Symphony, 'cause it's not part of the Osi bundle; dylp will present a
similar problem.

	At this point, I'm leaning toward defining a makefile conditional,
TREAT_FOO_AS_THIRD_PARTY, which could be used to distinguish the situations.

	Other suggestions are welcome.
	
							Lou