[BuildTools] Putting COIN projects `elsewhere'

[Ted Ralphs]

It seems to me that there may be some simpler solutions to this issue at 
play here. The easiest one is just to include all the COIN projects that 
have Osi interfaces as externals. What would be the objection to this? 
The download would be too big? It would take too long to compile?

If you are worried about the download being too big, then a simple 
solution would be to set up the configure script to look for projects 
like Cbc and SYMPHONY and build them if they are there---otherwise skip. 
Then anyone wanting those projects could simply modify their externals 
locally and those projects would automatically be included in the build. 
Wouldn't that be easier than treating them as third party? I guess the 
only problem might be compatibility of different version, but that will 
be a problem in any case.

Cheers,

Ted
Lou Hafer wrote:
> 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
> 
> _______________________________________________
> BuildTools mailing list
> BuildTools at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/buildtools


-- 
Dr. Ted Ralphs
Associate Professor
Industrial and Systems Engineering
Lehigh University
(610)758-4784
tkralphs at lehigh.edu
www.lehigh.edu/~tkr2