Xcode new settings & deprecated ones

[noresources]

Some settings related to header search paths have changed since Xcode 8-9. A new SYSTEM_HEADER_SEARCH_PATHS was introduced and HEADER_SEARCH_PATHS and ALWAYS_SEARCH_USER_PATHS have been deprecated. New settings fit better with premake API by the way.

I'd like to provide a pull request for that but the changes will break support for earlier Xcode version.

What is the policy for Xcode support ? Are you planning to provide a xcodeX action for each Xcode version like for Visual Studio ?

[starkos]

I'd like to hear what @samsinsane has to say, but I'd be inclined to go ahead and change it. Apple pushes pretty aggressively to keep people near the latest versions.

[samsinsane]

I agree - we're forced to update every time an iPad is updated to the latest version of iOS anyway.

[noresources]

I suppose most of people will be ok for moving ahead. On the other hand, my company for example deliver Macs to its clients and we never upgrade the installed OS. Currently, we have to keep somewhere a toolchain capable of building binaries for OSX 10.9.

Some settings have changed but the XCode file format didn't since Xcode 4.
The modification could be implemented as a set of xcodeN actions, "pointing" to the current xcode4 action with just little changes like

get current xcode target version from _ACTION // "xcode9" -> v9
if target version > 9, set SYSTEM_HEADER_SEARCH_PATHS
else set HEADER_SEARCH_PATHS

[starkos]

It sounds like you already had better informed opinion than I did. :) I'm fine with targeting specific Xcode versions; we do it for Visual Studio already. I don't know how accurate we'll be able to keep the generated projects with our small community, but I don't see any harm in doing it if someone finds value in it.

Look forward to the pull request, thanks in advance for the contribution!

[noresources]

Sorry for the 4 month delay. I was out of C/C++ development. I am about to submit a pull request for this and instead of adding a new action, I just added a new API xcodeversion (majorversion) to specify the target Xcode version.

project "foo"
  sysincludedirs ("foo/include")
  xcodeversion "8" -- use HEADER_SEARCH_PATHS
project "bar"
  sysincludedirs ("foo/include")
  -- xcodeversion not specified, 
  -- => use the latest Xcode version behavior (SYSTEM_HEADER_SEARCH_PATHS)

Does it sounds good to you ?

[starkos]

I just had to sort this for premake-next. The approach I came up with there was…

# Export for latest Xcode version
premake xcode

# Target a specific version
premake xcode=11

# Same deal for Visual Studio
premake vstudio
premake vstudio=2017

The target toolset should not be encoded in the project script; the point of Premake is to enable targeting the end-users environment and that can't happen if you hardcode it. You can workaround that limitation by force-setting _OPTIONS in your script, but that should be considered an advanced feature.

I chose the syntax I did because the vendors are starting to introduce new features and markup in between major releases, and at some point we're going to have to start testing against specific build numbers. More details to work out, but I'm trying to open the door for folks who need this level of control.

premake vstudio=14.0.25431.01

Should be possible to support this in v5 using _ARGS, if someone wants to tackle that.

[noresources]

That make sense. I am not sure to have enough time to implement it soon, so I submitted a PR that just use the new settings. This will fit 99% of use cases I guess.