Project

General

Profile

Feature #575

Investigate using cmake for configuration

Added by John Abbott almost 10 years ago. Updated about 1 month ago.

Status:
In Progress
Priority:
Normal
Assignee:
John Abbott
Category:
Portability
Target version:
CoCoALib-1.0
Start date:
20 Jun 2014
Due date:
% Done:

10%

Estimated time:
Spent time:
2.45 h

Description

The cmake program offers a platform independent "configuration" mechanism. In principle it could replace CoCoA's existing rather elaborate configuration arrangement.

Is cmake appropriate for CoCoALib/CoCoA? Investigate!

Related issues

Related to CoCoALib - Design #752: Investigate using Boost.build instead of makeNew2015-07-30

History

#1 Updated by John Abbott almost 10 years ago

Christof has been investigating using cmake for configuring normaliz/libnormaliz.

Good cmake seems to handle dependencies correctly and automatically; also the CMakeLists.txt file allows one to express fairly clearly(?!?) the structure of the project.

Bad it is not clear how to specify a custom "installation" of GMP instead of the standard system one; it is not clear how to extract the compilation options from GMP so that they can be used for the whole project.

Right now I find the negative aspects quite discouraging, almost to the point of declaring cmake unsuitable for CoCoALib (but that would be premature). I do not much like the idea of discard all the work put into the current shell-script+makefile system (but I also think that make is pretty terrible).

#2 Updated by Anna Maria Bigatti almost 10 years ago

John Abbott wrote:

Bad it is not clear how to specify a custom "installation" of GMP instead of the standard system one; it is not clear how to extract the compilation options from GMP so that they can be used for the whole project.

Right now I find the negative aspects quite discouraging, almost to the point of declaring cmake unsuitable for CoCoALib (but that would be premature). I do not much like the idea of discard all the work put into the current shell-script+makefile system (but I also think that make is pretty terrible).

I agree: we do need to allow custom installation of gmp (and boost)
We cannot give up make if we cannot rewrite the same functionalities with cmake.
Let's Christof work a bit longer on it ;-)

#3 Updated by John Abbott almost 10 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10

Christof is still trying to make cmake behave well on MacOS; both static and dynamic libraries give (different) problems.

He has not yet found a way of getting the -m64 compilation flag out of GMP. Probably in a few years' time it will all be irrelevant, but currently we still have to deal with awkward OSes (like mine) which don't really know whether they're 64-bit or 32-bit... :-(

cmake seemed to handle a fairly awkward directory name without trouble.

#4 Updated by Anna Maria Bigatti almost 7 years ago

  • Project changed from CoCoA to CoCoALib
  • Category changed from Portability to Portability
  • Assignee set to John Abbott
  • Target version set to CoCoALib-1.0

If I recall well someone (ICMS Seoul) suggested us to keep our handwritten configure.

This issue was under "CoCoA" instead of "CoCoALib".
I'm recovering these old and forgotten issues, so we reconsider them.

#5 Updated by John Abbott almost 7 years ago

We should talk to the Normaliz people again to see what they think of cmake after some time using it. I thought I had heard that they were abandoning cmake (in favour of "autotools"?)

#6 Updated by John Abbott about 1 month ago

This has been dormant for 7 years. Should we close/reject it?

Also available in: Atom PDF