[Cbc] CBC Installer for Windows

Alpár Jüttner alpar at cs.elte.hu
Thu Jul 14 10:32:32 EDT 2011


Hi,

> The bottom line is that even the effort involved in figuring out
> whether CMake is a viable alternative seems a bit too much. However,
> if you really want to convince me (and others) that this switch is
> possible and in the best interest of COIN, the most convincing case
> would be a proof-of-concept. How easy would it be to switch CoinUtils
> to CMake? This is the only stand-alone project in CoinAll, but even
> so, it is not so easy to configure and build. We need to detect and
> link with lots of third party software and we have nice mechanisms for
> doing so with the autotools. Do you know the autools well enough to
> look at what we have there and say what would be involved in switching
> (or even to implement the proof-of-concept). That's the only chance I
> see of thinking about a switch. Even then, it could only happen if you
> were willing to invest a lot of time with us getting it up and
> running.

OK. I had a short look at CoinUtils. It checks tons of compiler and std
lib capability, it can be done basically in the same way in CMAKE. It
also looks for some third party libs, namely
      * zlib, zblib. CMAKE has built in support for them.
      * LAPACK/BLAS. They provide CMAKE config, thus it is easy to check
        whether they are installed, and also to build from source as a
        subdirectory. You don't even need that messy source code
        reorganization that ThirdParty/Lapack currently does.
      * GLPK. We use it in LEMON, and have support both for checking if
        it is installed and for using it as a subdirectory. The later
        one needs a simple CMAKE config file, of course. (just like in
        ThirdParty/Glpk).
      * Sample and Netlib. I do not exactly know what they are.

Anyway, I'll go ahead and try to put together a demo CMAKE config for
CoinUtils. But it's clear that I'll have numerous questions. Which is
the best forum to ask about it?

> A more realtistic possibility would be to develop a simple CMake
> framework for building some of the core projects in the simplest
> configurations now, primarily to use for generating MSVC++ project
> files and making simple installers, but also maintain the autotools
> framework side-by-side for the more obscure configurations until CMake
> is full functional some years from now. We could then work on it
> slowly over time.

Indeed. Switching from autotools to CMAKE all at once would be a bad
idea.

Regards,
Alpar





More information about the Cbc mailing list