View Issue Details [ Jump to Notes ]

[ Print ]

Project

Category

View Status

Date Submitted

Last Update

0007745

CMake

public

2008-09-26 13:47

2008-09-26 14:28

Reporter

Torsten Rohlfing

Assigned To

Brad King

Priority

normal

Severity

feature

Reproducibility

always

Status

closed

Resolution

no change required

Platform

OS Version

Product Version

Target Version

Fixed in Version

Summary

0007745: CMake should not force compilers and compiler flags based on included projects' build settings

Description

When including other CMake-built projects, the new project is forced to use the same C/C++ compilers as well as compiler settings as the included projects.

Typical symptom, which we have all seen of course, is something like this:

  Warning: CMake is forcing CMAKE_CXX_FLAGS_DEBUG to "-g" to match that imported
  from VTK. If this message appears for more than one imported project, you have
  conflicting options and will have to re-build one of those projects.

Maybe there could be a way (CMake policy?) to disable this behaviour?

Additional Information

Obviously, there will be a heated debate and initial dismissal of this suggestion, so let me point out all the reasons why, in my opinion, having this restriction is a bad, bad idea.

First of all, it doesn't work. It's ineffective. It doesn't do what it's supposed to do.

Examples:

- When using a caching compiler frontend, e.g., ccache, the caching compiler and the non-caching compiler are really the same thing. Now say I use a pre-compiled VTK, then I cannot built my own project with the caching compiler, because VTK was built without caching.

- Compiler updates can break ABI compatibility without changing the path to the compiler. GCC 3.4 and 4.0 were both /usr/bin/g++, so for CMake they look like the same compiler, but they're incompatible.

Second, the restriction is absolutely unnecessary:

- There is no reason why I wouldn't be able to use different compiler flags in a projects than in an included library. For example, I recall that vnl used to require some floating-point flags to work properly, but for general use these flags degraded performance.

- When using packages NOT built with CMake, CMake doesn't know compiler and flags, so in these (common!) cases, we can do just fine without the restrictions placed on CMake projects.

On a more practical level, the current restriction makes it impossible to build a project for coverage testing (requires "-fprofile-arcs -ftest-coverage" compiler flags for GCC), if the project uses, say, a pre-built VTK without coverage testing.

Even if I build VTK with coverage tests: I don't want to coverage-test VTK, I want to test my own project. Being forced to build VTK with coverage testing is total overkill.

Tags

No tags attached.

Attached Files

Relationships

Notes
(0013602) Brad King (manager) 2008-09-26 14:25	There will be no heated debate. I agree 100%. The feature is left over from long ago when gcc was breaking its ABI with every release, CMake build settings were much simpler, and VTK was one of the only major CMake clients. The current behavior is because VTK still uses an out-dated (pre CMake 2.6) way to export its targets. VTK will be converted to use the target export/import mechanism eventually. The CMakeImportBuildSettings script must continue to do what it does now for compatibility reasons. It is up to VTK to stop using it. As an intermediate solution, a work-around has been added to this CMake script to help user projects skip the behavior. Add this to your project: set(CMAKE_OVERRIDE_COMPILER_MISMATCH 1) and there will be no forcing of settings.

(0013603) Brad King (manager) 2008-09-26 14:28	This workaround is already available in the CMake 2.6 release. If you want VTK to stop forcing build settings on users before it is converted to use the CMake 2.6 target export mechanism, please file a separate issue under the VTK project category.

Issue History
Date Modified	Username	Field	Change
2008-09-26 13:47	Torsten Rohlfing	New Issue
2008-09-26 14:05	Bill Hoffman	Status	new => assigned
2008-09-26 14:05	Bill Hoffman	Assigned To	=> Brad King
2008-09-26 14:25	Brad King	Note Added: 0013602
2008-09-26 14:28	Brad King	Status	assigned => closed
2008-09-26 14:28	Brad King	Note Added: 0013603
2008-09-26 14:28	Brad King	Resolution	open => no change required