[CMake] Odd Behavior in macOS Mojave

[Steven Stallion]

All,

It appears there have been some changes to how macOS handles the
system include path starting with macOS Mojave. It looks like Apple
has provided a workaround package you can install to re-instate the
/usr/include hierarchy, however I was wondering if this is something
that could be handled by AppleClang support?

Has anyone else encountered this yet?

Cheers,
Steve
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[Sean McBride]

Post by Steven Stallion
It appears there have been some changes to how macOS handles the
system include path starting with macOS Mojave. It looks like Apple
has provided a workaround package you can install to re-instate the
/usr/include hierarchy, however I was wondering if this is something
that could be handled by AppleClang support?

Could you elaborate? What odd behaviour are you seeing? Any error message to share? What 'workaround package' are you speaking of? What version of Xcode?

Cheers,
--
____________________________________________________________
Sean McBride, B. Eng ***@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[Steven Stallion]

Post by Sean McBride
Could you elaborate? What odd behaviour are you seeing? Any error message to share? What 'workaround package' are you speaking of? What version of Xcode?

We first noticed that some sources would fail to find certain system
headers (stddef.h in this case) when using Xcode 10 (also seen on
Xcode 10.1). It looks like Apple decided to relocate system include
paths under /Library /Developer and did away with /usr/include. After
some spelunking, it looks like this was tucked away in the release
notes for Xcode:
https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes

"The Command Line Tools package installs the macOS system headers
inside the macOS SDK. Software that compiles with the installed tools
will search for headers within the macOS SDK provided by either Xcode
at:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk

or the Command Line Tools at:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

depending on which is selected using xcode-select.

The command line tools will search the SDK for system headers by
default. However, some software may fail to build correctly against
the SDK and require macOS headers to be installed in the base system
under /usr/include. If you are the maintainer of such software, we
encourage you to update your project to work with the SDK or file a
bug report for issues that are preventing you from doing so. As a
workaround, an extra package is provided which will install the
headers to the base system. In a future release, this package will no
longer be provided. You can find this package at:

/Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg


To make sure that you're using the intended version of the command
line tools, run xcode-select -s <path to Xcode> or xcode select -s
/Library/Developer/CommandLineTools after installing."

Installing the package seemed to resolve the issues we had building
with AppleClang, which made me wonder if something is needed in the
platform modules to account for this change.

HTH,
Steve
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/

[Sean McBride]

Post by Steven Stallion
We first noticed that some sources would fail to find certain system
headers (stddef.h in this case) when using Xcode 10 (also seen on
Xcode 10.1). It looks like Apple decided to relocate system include
paths under /Library /Developer and did away with /usr/include. After
some spelunking, it looks like this was tucked away in the release
https://developer.apple.com/documentation/xcode_release_notes/
xcode_10_release_notes

I see. Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot "RogueResearch12" and indeed it does not have a /usr/include folder. It is however able to build CMake, VTK, and ITK nightly without any compiler errors.

Perhaps it's not so much a CMake bug as a bug in the project you're trying to build?

Cheers,
--
____________________________________________________________
Sean McBride, B. Eng ***@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[Steven Stallion]

Post by Sean McBride
I see. Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot "RogueResearch12" and indeed it does not have a /usr/include folder. It is however able to build CMake, VTK, and ITK nightly without any compiler errors.
Perhaps it's not so much a CMake bug as a bug in the project you're trying to build?

Interesting. I'll take another look - I wonder if it's a bad
interaction from calling clang from a custom command.

Thanks for taking a look!
Steve
--
Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[Bo Zhou]

At MacOS, in 99% cases, the build task always needs to setup the variables

- CMAKE_OSX_TARGET
- CMAKE_OSX_DEPLOYMENT_TARGET

This 2 variables are important. The CMAKE_OSX_TARGET would define the
minimal set of API during compilation, and this affects the built binary.
The second is the path to the OSX SDK, usually it stays
in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
. Since SDK changes file and directory structure according the language
feature, this is important to the program which has to use C++11 or C++14
or new header files.

Personally I only use 10.9 SDK, which is the first version migrated to
C++11, and SDK changed a lot compared to 10.8, and the program is
compatible with the later system.

Post by Sean McBride

Post by Sean McBride
I see. Well, I just checked my macOS 10.14.1 / Xcode 10.1 bot

"RogueResearch12" and indeed it does not have a /usr/include folder. It is
however able to build CMake, VTK, and ITK nightly without any compiler
errors.

Post by Sean McBride
Perhaps it's not so much a CMake bug as a bug in the project you're

trying to build?
Interesting. I'll take another look - I wonder if it's a bad
interaction from calling clang from a custom command.
Thanks for taking a look!
Steve
--
Powered by www.kitware.com
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
https://cmake.org/mailman/listinfo/cmake