MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0008598CMakeCMakepublic2009-02-24 15:232009-02-26 09:16
ReporterBrad King 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-6 
Target VersionFixed in Version 
Summary0008598: implicit include directory suppression may be outdated
DescriptionCMake suppresses generation of -I flags for /usr/include and optionally other directories listed in a CMAKE_PLATFORM_IMPLICIT_INCLUDE_DIRECTORIES variable (set to /usr/local/include on Mac). I've traced this behavior back to a change I made in 2001 with this comment:

"BUG: We don't want to output -I/usr/include in the INCLUDE_FLAGS variable. This causes problems with finding system headers in the wrong places for certain standard library implementations."

Today this behavior may be causing more trouble than it's worth. I do not remember more about the original problem, and modern gcc versions automatically ignore implicit include directories anyway.
Steps To Reproduce
Additional InformationIssue 0000116 added the CMAKE_PLATFORM_IMPLICIT_INCLUDE_DIRECTORIES variable.
Issues 0004342 and 0007407 describe cases where /usr/local/include should be allowed.
Issue 0008408 describes a case in which /usr/include should be allowed.
TagsNo tags attached.
Relationships
related to 0000116closed Bill Hoffman Implicit include directories like /usr/local/include cause warnings 
parent of 0004342closed Brad King CMAKE_OSX_SYSROOT and /usr/local/include 
parent of 0007407closed Brad King Xcode 3.1 and include_directories 
parent of 0008408closed Brad King /usr/include should not be omitted from include_directories() with gfortran 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2009-02-24 15:23Brad KingNew Issue
2009-02-24 15:23Brad KingStatusnew => assigned
2009-02-24 15:23Brad KingAssigned To => Brad King
2009-02-24 15:23Brad KingRelationship addedrelated to 0000116
2009-02-24 15:23Brad KingRelationship addedparent of 0004342
2009-02-24 15:24Brad KingRelationship addedparent of 0007407
2009-02-24 15:24Brad KingRelationship addedparent of 0008408
2009-02-24 15:37Brad KingNote Added: 0015339
2009-02-24 15:41Brad KingNote Added: 0015343
2009-02-24 15:41Brad KingStatusassigned => closed
2009-02-24 15:41Brad KingResolutionopen => fixed
2009-02-25 11:44Brad KingNote Added: 0015378
2009-02-25 11:44Brad KingStatusclosed => feedback
2009-02-25 11:44Brad KingResolutionfixed => reopened
2009-02-25 11:47Brad KingNote Added: 0015379
2009-02-25 11:47Brad KingStatusfeedback => closed
2009-02-25 11:47Brad KingResolutionreopened => fixed
2009-02-25 23:22Eric WingNote Added: 0015414
2009-02-25 23:22Eric WingStatusclosed => feedback
2009-02-25 23:22Eric WingResolutionfixed => reopened
2009-02-26 08:40Brad KingNote Added: 0015418
2009-02-26 09:16Brad KingNote Added: 0015422
2009-02-26 09:16Brad KingStatusfeedback => closed
2009-02-26 09:16Brad KingResolutionreopened => fixed

Notes
(0015339)
Brad King   
2009-02-24 15:37   
BUG: Remove implicit include dir suppression
/cvsroot/CMake/CMake/Modules/Platform/Darwin-icc.cmake,v <-- Modules/Platform/Darwin-icc.cmake
new revision: 1.2; previous revision: 1.1
/cvsroot/CMake/CMake/Modules/Platform/Darwin.cmake,v <-- Modules/Platform/Darwin.cmake
new revision: 1.58; previous revision: 1.57
/cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v <-- Source/cmLocalGenerator.cxx
new revision: 1.293; previous revision: 1.292
/cvsroot/CMake/CMake/Source/cmLocalGenerator.h,v <-- Source/cmLocalGenerator.h
new revision: 1.111; previous revision: 1.110
/cvsroot/CMake/CMake/Source/cmLocalUnixMakefileGenerator3.cxx,v <-- Source/cmLocalUnixMakefileGenerator3.cxx
new revision: 1.262; previous revision: 1.261
(0015343)
Brad King   
2009-02-24 15:41   
I've removed implicit include directory submission completely. If someone ever encounters the original problem we'll look at an alternative fix, or a more robust decision about suppressing things.
(0015378)
Brad King   
2009-02-25 11:44   
Well, it didn't take long for us to discover reasons to suppress -I/usr/include. The HP C++ compiler for example will gladly honor the flag and miss its replacements for C headers in its own private system include directory. It will also treat the directory as a user include directory and report warnings in its own headers.
(0015379)
Brad King   
2009-02-25 11:47   
I've created a new way to suppress these directories. It no longer hard-codes any paths in CMake's C++ code. The suppressions are now per-language. The default suppression list has only /usr/include for C and C++ but nothing for Fortran.

ENH: Re-enable system include dir suppression
/cvsroot/CMake/CMake/Modules/Platform/UnixPaths.cmake,v <-- Modules/Platform/UnixPaths.cmake
new revision: 1.14; previous revision: 1.13
/cvsroot/CMake/CMake/Source/cmDocumentVariables.cxx,v <-- Source/cmDocumentVariables.cxx
new revision: 1.27; previous revision: 1.26
/cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v <-- Source/cmLocalGenerator.cxx
new revision: 1.294; previous revision: 1.293
(0015414)
Eric Wing   
2009-02-25 23:22   
I don't know the original origins of this in 2001, but I recall in Mac OS X Tiger after the introduction of Intel and the SDK stuff (circa 2006), we encountered a really nasty gcc bug on the platform that would cause it to get confused by redundant -I/usr/include paths since it was trying to remap/hide those paths to force the system to look inside the SDKs instead. This resulted in strange build failures and wrong things being pulled in and I recall it was something that was very hard to track down. So when using SDKs, /usr/include had to be suppressed at the time.

Now with Leopard and Xcode 3.1, they've changed a lot of things and hopefully fixed some of those bugs. (Though I don't know for sure.)

But for sure, header suppression of /usr/local/include (not /usr/include) is causing me great pain on Leopard/Xcode 3.1. /usr/local/include is not technically an official Apple directory, so it is debatable whether it should have been suppressed in the first place.

I request a solution to avoid suppressing this directory as I have stuff in there that needs to be included. Header suppression still seems active as of the 2.6.3 official release.

I would suggest that maybe the header suppression go away for /usr/local/include on the Mac. You might give yourself the option of detecting Leopard vs Tiger. On Leopard, you might try doing-away with header suppression and leaving it for Tiger if you are concerned about breaking Tiger.

I suspect keeping header suppression for /usr/include might be a good thing if you want to play it safe.
(0015418)
Brad King   
2009-02-26 08:40   
Read my previous post again. I didn't say it explicitly, but the new implementation does not do /usr/local/include on Mac. Since 2.6.3 was released before the last 2 days of changes in CVS HEAD, it does not include the fixes. I've already put the changes in my scheduling branch for 2.6.4 (not yet in the CVS branch though).
(0015422)
Brad King   
2009-02-26 09:16   
My first commit of the new implementation worked only for Makefile generators. I've updated the implementation to be in the central include directory computation code shared by all generators. The project-file generators which do not distinguish between C and C++ include paths just use the C rules for simplicity.

BUG: Use new include dir suppresson for all gens
/cvsroot/CMake/CMake/Source/cmLocalGenerator.cxx,v <-- Source/cmLocalGenerator.cxx
new revision: 1.296; previous revision: 1.295
/cvsroot/CMake/CMake/Source/cmLocalGenerator.h,v <-- Source/cmLocalGenerator.h
new revision: 1.112; previous revision: 1.111