[BuildTools] Putting COIN projects `elsewhere'

[Andreas Waechter]

Hi

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".

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

Andreas


On Mon, 14 May 2007, Lou Hafer wrote:

> Ted,
>
>> 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?
>
>    Size is certainly an issue.  Kassman was also commenting that in the
>    build system that he's constrained to use, it's much easier to handle
>    components individually.  Also, Externals is only an option if you're
>    working from the svn repository. Third-party is needed if you're working
>    from tarballs.
>
>> 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.
>
>    True.  Could, and should, be done.  Cbc does this with DyLP.  I'll put
>    it on my maintenance list for Osi.
>
>> 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.
>
>    I suspect that all of us developers have been doing exactly what you
>    suggest --- modifying Externals and then doing some minor hacking of
>    configure.ac.  But I'd still find it convenient to be able to test
>    OsiFoo without having to put Foo's source tree into the Osi project
>    bundle, given that I already have Foo built in another tree. If nothing
>    else, it saves me time when I try to commit configuration changes,
>    'cause I don't have to back out tweaks related to non-standard
>    Externals.
>
>    For non-developers, I suspect that the third-party style is more what
>    they're used to using.
>
>    What I'm aiming for, in the end, is a top-level configure.ac that will
>    decide whether you have Foo as a source tree in the standard place
>    (acquired via Externals, or whatever), or whether you have it as
>    `third-party', or whether it's entirely absent.
>
> 							Lou
>
> _______________________________________________
> BuildTools mailing list
> BuildTools at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/buildtools
>