* Add mode argument ot toolset.getrunpathdirs()
* Add config.getsiblingtargetdirs()
* Delegate automatic addition of sibling target dirs as run path search paths to actions
* Simplify gcc.getrunpathdirs()
* Restore previous behavior in gmake & gmake2 actions
* Add xcode.getToolSet()
Use clang as default, gcc on MacOS X 10.6 and lower
* runpathdirs support in xcode4 action
Translate runpathdirs to LD_RUNPATH_SEARCH_PATHS Xcode setting
Co-authored-by: Renaud Guillard <renaud@depinxi.be>
When entries in links are specified with an extension we treat them
like frameworks for the most part. They are placed into the
Frameworks group and added to the Frameworks build phase. We do have
separate logic for the file reference, only because we never want to
resolve a .dylib link to the /System/Frameworks directory. Instead
we assume a .dylib link that is just a file name, e.g. 'libA.dylib',
is relative to the project the same way as if it were prefixed with
'./'.
Added new warning level "Everything" which turns on all available
compiler warnings. Updated "High" and "Extra" to reflect actual
differences in emitted compiler flags.
When a build command contains a token which references a configuration, ex. `{cfg.platform}`, the platform optimizations removed by this commit would cause a crash: "Attempt to index a nil value (global 'cfg')".
Fixes#1013
Per the discussion in issue #1336, if systemversion is set
output MACOSX_DEPLOYMENT_TARGET into the resulting xcode project.
This borrows a diff from the (unmerged) PR #1003, applies it
in isolation, and adds a pair of unit tests to confirm that both
setting and not setting the systemversion results in correct
output.
Closes#1336
- Add "Use … instead." messages to any deprecations that did not have one
- Change deprecation date on APIs without a message to current date
- Remove APIs that have been deprecated for more than a year
h/t to @samsinsane for original PR on which this is based (#741)
I must not have been on the latest revision when I merged the Xcode module into core. This catches things back up to the state of the submodule repository.
As discussed numerous times, get rid of the submodule approach for core modules and just included the sources directly in the main repository.
I have no idea how this will play with existing working copies. It might be necessary to [manually clear out the existing submodules](http://stackoverflow.com/questions/1260748) first.
