summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalXCodeGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* cmGlobalXCodeGenerator: Rename variable 'lang' => 'llang'Brad King2015-02-061-7/+7
| | | | | In CreateBuildSettings the variable holds the linker language. Use a more distinctive variable name.
* Xcode: Generate Intel Fortran compiler flags in project filesBrad King2015-02-061-0/+5
|
* Xcode: Refactor generation of per-language compiler flagsBrad King2015-02-061-71/+69
|
* Xcode: Switch to internal CMAKE_MAKE_PROGRAM lookup by generator (#15324)Brad King2015-01-291-1/+13
| | | | | | | | | | | | The "cmakexbuild" wrapper is not needed for Xcode 4 and above, and the path to it may change when CMake moves. Avoid storing a specific path to a build program in CMakeCache.txt and instead compute the value for CMAKE_MAKE_PROGRAM on demand. However, if a user does set the value explicitly then honor it. This does for Xcode what commit v3.0.0-rc1~260^2~4 (VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generators, 2013-11-15) did for Visual Studio generators.
* Xcode: Select make program at build timeBrad King2015-01-281-1/+1
| | | | | | | Extend the change made in commit v3.0.0-rc1~260^2~16 (Teach GenerateBuildCommand to find its own make program, 2013-11-13) to have the Xcode generator pick between "xcodebuild" and CMake's own copy of "cmakexbuild" at build time based on the version of Xcode.
* Xcode: Add internal API to find xcodebuildBrad King2015-01-281-0/+31
| | | | | | | | Teach the Xcode generator to compute the location of this tool or the cmakexbuild wrapper. Add internal APIs to get the locations on demand. Use the "cmakexbuild" wrapper for Xcode < 4, and "xcodebuild" for modern Xcode.
* Merge topic 'xcode-target-sort'Brad King2015-01-201-11/+51
|\ | | | | | | | | | | 9e0176e2 Xcode: Sort targets deterministically and with ALL_BUILD first (#15346) c0ff542c Xcode: Fix early termination on per-config source file error
| * Xcode: Sort targets deterministically and with ALL_BUILD first (#15346)Ben Boeckel2015-01-191-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | The default target in XCode is the first one in the file. In commit v3.1.0-rc1~286^2 (cmTarget: use a hash_map for cmTargets typedef, 2014-06-10) the order of the targets stored in cmMakefile was made non-deterministic instead of lexicographic. Teach the Xcode generator to do its own sorting to restore a predictable order. While at it, place ALL_BUILD first (as is done in VS IDE generators) explicitly in the comparison function so that it is the default target even if other targets sort earlier lexicographically (e.g. "AAA").
| * Xcode: Fix early termination on per-config source file errorBrad King2015-01-191-10/+26
| | | | | | | | | | | | | | | | | | In commit v3.1.0-rc1~687^2~4 (cmTarget: Make the source files depend on the config, 2014-02-13) an early termination case was added to the Xcode generator. Fix handling of this case to actually abort all the generation steps. Otherwise some of the later steps are attempted without the preconditions normally established by earlier steps, possibly leading to a crash.
* | Port all cmOStringStream to std::ostringstream.Stephen Kelly2015-01-111-4/+4
| | | | | | | | All compilers hosting CMake support the std class.
* | Xcode: Call IsCFBundleOnApple to decide if bundle is being builtGregor Jasny2014-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | Narrow down the decision if a CFBundle is built to one place. This is a preparation patch to add another target property which, if set, will imply BUNDLE. Having only one function which will have to look at both properties helps to keep code clean. Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
* | Xcode: Fix rebuild with multiple custom command outputs (#15116)Brad King2014-12-051-50/+11
| | | | | | | | | | | | | | | | The Xcode generator uses Makefiles under a run-script build-phase to drive custom commands. Fix the generated makefiles for custom commands with multiple outputs to list all the outputs on the left hand side of the build rule. This is much simpler and more reliable than the old multiple-output-pair infrastructure.
* | Xcode: use a map to look up target pointers (#15201)Ben Boeckel2014-12-021-8/+9
| | | | | | | | | | Use an efficient internal lookup to associate cmTarget and cmXCodeObject instances.
* | Add an option for explicit BYPRODUCTS of custom commands (#14963)Brad King2014-11-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A common idiom in CMake-based build systems is to have custom commands that generate files not listed explicitly as outputs so that these files do not have to be newer than the inputs. The file modification times of such "byproducts" are updated only when their content changes. Then other build rules can depend on the byproducts explicitly so that their dependents rebuild when the content of the original byproducts really does change. This "undeclared byproduct" approach is necessary for Makefile, VS, and Xcode build tools because if a byproduct were listed as an output of a rule then the rule would always rerun when the input is newer than the byproduct but the byproduct may never be updated. Ninja solves this problem by offering a 'restat' feature to check whether an output was really modified after running a rule and tracking the fact that it is up to date separately from its timestamp. However, Ninja also stats all dependencies up front and will only restat files that are listed as outputs of rules with the 'restat' option enabled. Therefore an undeclared byproduct that does not exist at the start of the build will be considered missing and the build will fail even if other dependencies would cause the byproduct to be available before its dependents build. CMake works around this limitation by adding 'phony' build rules for custom command dependencies in the build tree that do not have any explicit specification of what produces them. This is not optimal because it prevents Ninja from reporting an error when an input to a rule really is missing. A better approach is to allow projects to explicitly specify the byproducts of their custom commands so that no phony rules are needed for them. In order to work with the non-Ninja generators, the byproducts must be known separately from the outputs. Add a new "BYPRODUCTS" option to the add_custom_command and add_custom_target commands to specify byproducts explicitly. Teach the Ninja generator to specify byproducts as outputs of the custom commands. In the case of POST_BUILD, PRE_LINK, and PRE_BUILD events on targets that link, the byproducts must be specified as outputs of the link rule that runs the commands. Activate 'restat' for such rules so that Ninja knows it needs to check the byproducts, but not for link rules that have no byproducts.
* | Xcode: Inherit global settings in per-target WARNING_CFLAGS (#15224)Brad King2014-10-311-0/+1
|/ | | | | Allow projects to use CMAKE_CODE_ATTRIBUTE_WARNING_CFLAGS to add their own warning flags and have them used by the targets.
* cmGlobalGenerator: Call SetGeneratorToolset even for empty toolsetBrad King2014-09-051-2/+5
| | | | | | Move handling of an empty toolset name into the implementation of the method. This simplifies the VS 10 implementation of default toolset selection because it has one code path that is always called.
* Merge topic 'xcode-duplicate-file-refs'Brad King2014-09-041-6/+4
|\ | | | | | | | | | | | | d73f8828 Merge branch 'backport-xcode-duplicate-file-refs' into xcode-duplicate-file-refs cf92fe2d Xcode: Generate per-target file references (#15111) e7114226 Xcode: Generate per-target file references (#15111)
| * Xcode: Generate per-target file references (#15111)Brad King2014-09-031-6/+4
| | | | | | | | | | | | | | Xcode requires a separate PBXFileReference for each target source group that references a source file. Xcode 6 now diagnoses re-use of the same PBXFileReference from multiple source groups. Add the referencing target name to our internal map key so we use a per-target reference.
* | Xcode: Reference '.xcassets' folders as assetcatalog (#15125)Brad King2014-09-031-1/+1
| |
* | Xcode: Refactor internal file type extension extractionBrad King2014-09-031-7/+7
|/ | | | Move it earlier so it can be used for directories too.
* Merge topic 'xcode-6-librarian-flags'Brad King2014-07-291-5/+23
|\ | | | | | | | | 608cf814 Xcode: Fix static library creation for Xcode 6 (#15038)
| * Xcode: Fix static library creation for Xcode 6 (#15038)Brad King2014-07-281-5/+23
| | | | | | | | | | | | | | | | | | Xcode 6 introduced an 'OTHER_LIBTOOLFLAGS' setting for the "Other Librarian Flags" of a static library. Now 'OTHER_LDFLAGS' are ignored. Teach the Xcode generator to choose the correct name for the build setting based on the type of target and the version of Xcode. Inspired-by: Jamie Kirkpatrick <jkp@spotify.com>
* | cmTarget: Remove 'head' argument from GetLinkImplementationBrad King2014-06-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Many of the 'head' arguments added by commit v2.8.11~289^2~1 (Make linking APIs aware of 'head' target, 2013-01-04) turned out not to be needed. The "link implementation" of a target never needs to be computed with anything but itself as the 'head' target (except for CMP0022 OLD behavior because then it is the link interface). Remove the unused 'head' target paths. Add "internal" versions of cmTarget::GetDirectLinkLibraries and GetLinkImplementationLibraries to support the CMP0022 OLD behavior without otherwise exposing the 'head' target option of these methods.
* | Merge topic 'xcode-15-string-apis'Brad King2014-06-061-13/+5
|\ \ | | | | | | | | | | | | 23dc6aa1 Xcode: Fix single-configuration generation for version 1.5
| * | Xcode: Fix single-configuration generation for version 1.5Brad King2014-06-051-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | In commit 84fdc992 (stringapi: Pass configuration names as strings, 2014-02-09) a few code paths for the Xcode 1.5 single-configuration generator were not updated to use an empty configuration name instead of a NULL pointer when no configuration is specified in CMAKE_BUILD_TYPE. Fix them now.
* | | Allow a toolchain file to specify a generator toolsetBrad King2014-06-041-7/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake file has been configured and loaded during the first project() or enable_language() command. This gives the toolchain file named by CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This point is still early enough to set the generator toolset prior to the initialization of any languages that might use the toolset. The cmake::GeneratorToolset member variable remains an indication of what was specified by the -T option or loaded from the cache. It does not need to be updated based on the toolchain file setting. The cmMakefile::TryCompile can still pass cmake::GeneratorToolset into the inner instance because the try-compiled project will do platform and language initialization using the CMakeSystem module configured for the outer project. Extend the RunCMake.GeneratorToolset test with cases that use a toolchain file to set CMAKE_GENERATOR_TOOLSET.
* | | Xcode: Rename internal variable {Platform => Generator}ToolsetBrad King2014-06-041-5/+5
|/ / | | | | | | The latter matches with CMAKE_GENERATOR_TOOLSET better.
* | Xcode: Add source file property to control file type (#14854)Brad King2014-05-151-6/+21
| | | | | | | | | | | | | | | | | | Add source file properties to control Xcode file type attributes: XCODE_EXPLICIT_FILE_TYPE => explicitFileType XCODE_LAST_KNOWN_FILE_TYPE => lastKnownFileType Add a RunCMake.XcodeProject test to verify generated project content.
* | Xcode: Refactor internal source file type selectionBrad King2014-05-151-26/+26
| | | | | | | | | | | | | | Choose the attribute name and file type and send them through a single attribute generation code path. Compute the file extension only when needed. Leave the file type selection logic indented in a block so it can be made conditional later.
* | cmGlobalGenerator: Store targets in hash mapsBen Boeckel2014-05-071-1/+1
| |
* | cmTarget: Make the source files depend on the config.Stephen Kelly2014-04-021-8/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Disallow the use of config-specific source files with the Visual Studio and Xcode generators. They don't have any way to represent the condition currently. Use the same common-config API in cmQtAutoGenerators. While it accepts config-specific files, it doesn't have to support multiple configurations yet. Loop over the configs in cmTargetTraceDependencies and cmGlobalGenerator::WriteSummary and consume all source files. Loop over the configs in cmComputeTargetDepends and compute the object library dependencies for each config.
* | cmGeneratorTarget: Compute target objects on demandStephen Kelly2014-04-021-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a ComputeObjectMapping method to compute the object names. It takes mapping to populate as an out-parameter so that it can be extended in the future with parameters relevant to generator expression evaluation. Remove the supporting cmGeneratorTarget::AddObject method. It is no longer needed as the container member is populated directly. The ComputeObjectMapping method is called whenever objects are requested from the cmGeneratorTarget. Because the Xcode generator makes no such request, explicitly invoke the method from that generator so that the logic of checking for bad sources in object libraries is executed. In a follow-up, the UseObjectLibraries usage may be replaced by a true generator expression evaluator for TARGET_OBJECTS. That will require generators to use cmGeneratorTarget::GetExternalObjects which is not currently the case for Xcode and VS generators.
* | cmTarget: Allow any generator expression in SOURCES property.Stephen Kelly2014-04-021-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove use of UseObjectLibraries from Makefile and Ninja generators. It is not needed now because those generators use GetExternalObjects which already contains the objects from object libraries. The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects methods. Ensure that duplicates are not created by skipping objects from object libraries in handling of GetExternalObjects. Similarly, fix VS6, VS7 and Xcode object handling by skipping external objects from OBJECT_LIBRARY usage as appropriate. The error message in the BadSourceExpression1 test is now reported by the generator expression evaluator, so it has different text.
* | cmGlobalGenerator: Add interface to call ForceLinkerLanguagesStephen Kelly2014-03-311-1/+0
| | | | | | | | | | Avoid calling it too early when cmGeneratorTarget instances don't yet exist.
* | cmTarget: Use string API to add sources to cmTarget objects.Stephen Kelly2014-03-311-3/+3
| | | | | | | | | | Continue to call GetOrCreateSource where necessary to create cmSourceFile objects which have the GENERATED attribute set.
* | cmTarget: Rename AddSource method for backward compatibility.Stephen Kelly2014-03-311-2/+2
| | | | | | | | Add a new AddSource method for future use.
* | cmGlobalGenerator: Make ComputeTargetObjects non-virtualStephen Kelly2014-03-151-24/+0
| | | | | | | | | | | | | | | | Implement it in terms of the ComputeObjectFilenames virtual method on the local generators. Remove the reimplementation from the global generators which are now all functionally identical.
* | cmLocalGenerator: Add ComputeObjectFilenames interface.Stephen Kelly2014-03-131-19/+11
| | | | | | | | | | Implement it in the local generators and use it in the global generators.
* | cmGeneratorTarget: Constify cmSourceFile* in containers.Stephen Kelly2014-03-131-3/+3
| | | | | | | | | | Some of them will be used with other APIs which require value_type to be cmSourceFile const*.
* | cmGlobalGenerator: Extract a ComputeTargetObjectDirectory interface.Stephen Kelly2014-03-131-0/+5
| | | | | | | | Make it public for future external calls.
* | Generalize cmCustomCommandGenerator to more fieldsBrad King2014-03-121-15/+14
| | | | | | | | | | | | | | Until now the cmCustomCommandGenerator was used only to compute the command lines of a custom command. Generalize it to get the comment, working directory, dependencies, and outputs of custom commands. Update use in all generators to support this.
* | cmGlobalXCodeGenerator: Simplify handling of multiple outputsBrad King2014-03-121-31/+18
| | | | | | | | | | Make the multiple output pair map more local. Generate it where we have the current configuration available.
* | cmCustomCommand: Return std::string from GetWorkingDirectoryBrad King2014-03-121-2/+3
| |
* | stringapi: Use strings for program pathsBen Boeckel2014-03-081-1/+1
| |
* | stringapi: Use strings for generator namesBen Boeckel2014-03-081-3/+4
| |
* | stringapi: Use strings for directoriesBen Boeckel2014-03-081-1/+1
| |
* | stringapi: Miscellaneous char* parametersBen Boeckel2014-03-081-7/+7
| |
* | stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-16/+11
| |
* | strings: Remove cmStdString referencesBen Boeckel2014-03-081-41/+41
| | | | | | | | | | | | | | | | | | | | | | Casts from std::string -> cmStdString were high on the list of things taking up time. Avoid such implicit casts across function calls by just using std::string everywhere. The comment that the symbol name is too long is no longer relevant since modern debuggers alias the templates anyways and the size is a non-issue since the underlying methods are generated since it's inherited.
* | stringapi: Use strings for VS project namesBen Boeckel2014-03-081-1/+1
| |
generated by cgit v0.12 at 2024-11-08 20:38:36 (GMT)