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
On Wed, Nov 14, 2018 at 10:54 AM Sean McBride wrote:
> 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
On Wed, 14 Nov 2018 10:43:28 -0600, Steven Stallion said:
>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
On Wed, Nov 14, 2018 at 8:19 AM Sean McBride wrote:
> 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
On Tue, 13 Nov 2018 18:42:43 -0600, Steven Stallion said:
>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
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
