MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0007745CMakeCMakepublic2008-09-26 13:472008-09-26 14:28
ReporterTorsten Rohlfing 
Assigned ToBrad King 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007745: CMake should not force compilers and compiler flags based on included projects' build settings
DescriptionWhen 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?
Steps To Reproduce
Additional InformationObviously, 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.
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2008-09-26 13:47Torsten RohlfingNew Issue
2008-09-26 14:05Bill HoffmanStatusnew => assigned
2008-09-26 14:05Bill HoffmanAssigned To => Brad King
2008-09-26 14:25Brad KingNote Added: 0013602
2008-09-26 14:28Brad KingStatusassigned => closed
2008-09-26 14:28Brad KingNote Added: 0013603
2008-09-26 14:28Brad KingResolutionopen => no change required

Notes
(0013602)
Brad King   
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   
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.