[BuildTools] Putting COIN projects `elsewhere'

[Lou Hafer]

Andreas,

> I think the idea of having an option, where a *precompiled* COIN project 
> (with all internals, not just /lib /bin etc) is located, is feasible. 
> Thing is that we currently didn't set up things to compile a COIN project 
> on its own, only within a "package".

    I did give some thought to the idea of specifying an alternate location
    for the source tree.  But (at least for Kassman, who got me started on
    this) it's clear that what's desired is the ability to prebuild the COIN
    component someplace else, and then possibly relocate the libraries and
    include files to some collection point, absent the rest of the source
    tree (the usual `make install' function).  At that point, the notion of
    `treat as third-party' took hold.

> But, this brings us back to the problem of having possibly inconsistent 
> versions...

    Yeah, sad to say, it does.  I don't see an easy way around that.  Partly
    we're talking about people who want to go beyond the prepackaged project
    bundle.  Hooking every possible component into Osi will make the tarball
    seriously unwieldy.  Manipulating externals works only from the
    repository.  We must be at a local maximum; there are downsides in all
    directions :-)

    I guess the corporate line would be that versions specified in externals
    are guaranteed compatible.  `Treat as third-party' is available, use at
    your own risk.
    
    An alternate way to look at it is that we could reduce individual
    project tarballs to some minimum configuration (specified via externals)
    and add a `suggested versions' file for things that fall into the `treat
    as third-party' category.  It's reasonable to ask, for example, why dylp
    is in the default Osi tarball, but Cbc/Cgl and/or Symphony are not.  All
    are COIN components, all have Osi interfaces.  As above, I can see
    upsides and downsides.
    
    Gotta run. Office hour.

							Lou