View Issue Details [ Jump to Notes ] [ Print ]
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.
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.
Attached Files

 Relationships
related to 0000116closedBill Hoffman Implicit include directories like /usr/local/include cause warnings 
parent of 0004342closedBrad King CMAKE_OSX_SYSROOT and /usr/local/include 
parent of 0007407closedBrad King Xcode 3.1 and include_directories 
parent of 0008408closedBrad King /usr/include should not be omitted from include_directories() with gfortran 

  Notes
(0015339)
Brad King (manager)
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 (manager)
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 (manager)
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 (manager)
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 (reporter)
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 (manager)
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 (manager)
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

 Issue History
Date Modified Username Field Change
2009-02-24 15:23 Brad King New Issue
2009-02-24 15:23 Brad King Status new => assigned
2009-02-24 15:23 Brad King Assigned To => Brad King
2009-02-24 15:23 Brad King Relationship added related to 0000116
2009-02-24 15:23 Brad King Relationship added parent of 0004342
2009-02-24 15:24 Brad King Relationship added parent of 0007407
2009-02-24 15:24 Brad King Relationship added parent of 0008408
2009-02-24 15:37 Brad King Note Added: 0015339
2009-02-24 15:41 Brad King Note Added: 0015343
2009-02-24 15:41 Brad King Status assigned => closed
2009-02-24 15:41 Brad King Resolution open => fixed
2009-02-25 11:44 Brad King Note Added: 0015378
2009-02-25 11:44 Brad King Status closed => feedback
2009-02-25 11:44 Brad King Resolution fixed => reopened
2009-02-25 11:47 Brad King Note Added: 0015379
2009-02-25 11:47 Brad King Status feedback => closed
2009-02-25 11:47 Brad King Resolution reopened => fixed
2009-02-25 23:22 Eric Wing Note Added: 0015414
2009-02-25 23:22 Eric Wing Status closed => feedback
2009-02-25 23:22 Eric Wing Resolution fixed => reopened
2009-02-26 08:40 Brad King Note Added: 0015418
2009-02-26 09:16 Brad King Note Added: 0015422
2009-02-26 09:16 Brad King Status feedback => closed
2009-02-26 09:16 Brad King Resolution reopened => fixed

Copyright © 2000 - 2018 MantisBT Team