summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalXCodeGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* stringapi: Use strings in target nameBen Boeckel2014-03-081-11/+12
|
* stringapi: Use strings for the languagesBen Boeckel2014-03-081-24/+17
|
* stringapi: Use strings for AddString methodsBen Boeckel2014-03-081-1/+1
| | | | It gets turned into a string anyways, so pass them in.
* cmTarget: Move SourceFileFlags to cmGeneratorTarget.Stephen Kelly2014-02-241-13/+15
|
* OS X: Make sure RPATHs are unique to avoid possible corruption.Clinton Stimpson2014-02-031-3/+37
| | | | | | | | When using link_directories() and including CMAKE_CFG_INTDIR, one can end up with duplicate RPATHs in the binary which install_name_tool cannot fix without corrupting the binary. Also, the cmake_install.cmake file has been fixed to correctly handle these generator specific variables.
* cmMakefile: Make FindSourceGroup const.Stephen Kelly2014-01-221-4/+4
| | | | | Return a pointer instead of a reference. This allows making the accessor const with the least impact.
* Xcode: Fix storyboard viewRuslan Baratov2014-01-161-3/+9
| | | | | | | Images and xib files must have 'lastKnownFileType' attribute to be displayed correctly. If xib file has attribute 'explicitFileType' it is displayed as raw xml. If static image has attribute 'explicitFileType' it is displayed as question mark on storyboard.
* Xcode: Remove dead codeRuslan Baratov2014-01-161-4/+0
| | | | | Variable 'ext' already checked for equality to "xib" so remove the branch that will never be executed.
* cmTarget: Make GetSourceFiles populate an out-vector parameter.Stephen Kelly2014-01-091-4/+8
| | | | | In a future patch, this will also be populated with extra sources from the linked dependencies.
* cmGeneratorTarget: Add methods to access source file groups.Stephen Kelly2014-01-091-3/+5
| | | | | These methods and others will be able to get a config parameter later to implement the INTERFACE_SOURCES feature.
* Xcode: Fix storyboard viewRuslan Baratov2014-01-071-1/+4
| | | | | | | | | | Since commit 56831461 (Xcode: Use explicitFileType to mark source types, 2013-04-16) the Xcode generator prefers to use explicitFileType to tell Xcode about each source file type. This works better than lastKnownFileType for some file types, but not for "file.storyboard". If storyboard file has attribute 'explicitFileType' it is displayed incorrectly (as raw xml). Switch it back to 'lastKnownFileType'.
* cmTarget: Remove some of the INTERFACE_LIBRARY whitelisted properties.Stephen Kelly2014-01-061-1/+2
| | | | | | | | | | | There is no need to allow EXCLUDE_* properties, because an INTERFACE_LIBRARY has no direct build output. IMPORTED_LINK_INTERFACE_LANGUAGES are relevant only to static libraries. VERSION is relevant only to the filename of direct build outputs, which INTERFACE_LIBRARY does not have.
* Constify handling of target dependencies.Stephen Kelly2013-12-111-1/+1
|
* Xcode: Fix duplicate target subfolders (#14133)Stephan Tolksdorf2013-12-021-7/+7
| | | | | | | Fix logic introduced by commit eeeeca10 (XCode: Support target folders on XCode, 2011-02-20) to avoid duplicate subfolders. The problem was that no slash was appended to the curr_tgt_folder string on the it != this->TargetGroup.end() path.
* Teach GenerateBuildCommand to find its own make programBrad King2013-11-181-7/+3
| | | | | | | | Add a cmGlobalGenerator::SelectMakeProgram method to select a caller-provided make program, the CMAKE_MAKE_PROGRAM cache entry, or a generator-provided default. Call it from all implementations of the GenerateBuildCommand method with the corresponding generator's default, if any.
* cmGlobalGenerator: Cleanup GenerateBuildCommand APIBrad King2013-11-181-37/+29
| | | | | | | | | All cmGlobalGenerator::GenerateBuildCommand call sites that need to produce a string now generate "cmake --build" commands. The remaining call sites immediately pass the result to cmSystemTools::RunSingleCommand. Avoid the intermediate string and argument parsing by directly producing a vector of strings. Also drop the ignoreErrors argument because no call sites remain that use it.
* Xcode: Generate 'folder' source type for directories (#14498)Michael Priestman2013-10-211-5/+16
| | | | | | Teach the Xcode generator to set 'lastKnownFileType' to be 'folder' for file references that are directories. If you set 'explicitFileType' to 'sourcecode', then Xcode cannot browse the directory.
* Drop the 'Full' field from cmDocumentationEntryBrad King2013-10-161-1/+0
| | | | | We need only 'Brief' for usage documentation. We no longer have builtin 'Full' documentation, which is now in Help/*/*.rst files.
* Add the INTERFACE_LIBRARY target type.Stephen Kelly2013-10-071-1/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | This target type only contains INTERFACE_* properties, so it can be used as a structural node. The target-specific commands enforce that they may only be used with the INTERFACE keyword when used with INTERFACE_LIBRARY targets. The old-style target properties matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for this target type. The name of the INTERFACE_LIBRARY must match a validity generator expression. The validity is similar to that of an ALIAS target, but with the additional restriction that it may not contain double colons. Double colons will carry the meaning of IMPORTED or ALIAS targets in CMake 2.8.13. An ALIAS target may be created for an INTERFACE library. At this point it can not be exported and does not appear in the buildsystem and project files are not created for them. That may be added as a feature in a later commit. The generators need some changes to handle the INTERFACE_LIBRARY targets returned by cmComputeLinkInterface::GetItems. The Ninja generator does not use that API, so it doesn't require changes related to that.
* Xcode: Fix OBJECT library support for Xcode 5 (#14254)Brad King2013-10-021-19/+40
| | | | | | | | | | | | | | | Xcode 2.1 through 4 supported $(CURRENT_ARCH) in a PBXFileReference 'path' value used in the "Link Binary with Libraries" build phase. CMake uses this to reference object file locations on link lines to bring in OBJECT library content. However, Xcode 5 now evaluates the $(CURRENT_ARCH) reference in this context as "undefined_arch" so the wrong path is given to the linker. There seems to be no alternative way to produce an architecture-specific value in a PBXFileReference. Fortunately Xcode 5 now also handles link dependencies for paths linked through OTHER_LDFLAGS. For Xcode >= 5, move the OBJECT library object file references from the link build phase to OTHER_LDFLAGS. We can still show the object files in the source group listing in either case.
* Xcode: Drop XCODE_DEPEND_HELPER for Xcode >= 5Brad King2013-10-021-12/+19
| | | | | | Xcode 5.0 now computes dependencies from files linked through OTHER_LDFLAGS, so we no longer need the XCODE_DEPEND_HELPER hack to re-link dependents when targets change.
* Unify the way the flags of a static library are readPatrick Gansterer2013-07-311-15/+19
| | | | | Introduce cmLocalGenerator::GetStaticLibraryFlags() to have a central function for getting the linker flags for a given target.
* Refactor cmTarget::GetCompileDefinitions to use an out-vector, not a string.Stephen Kelly2013-07-111-2/+3
| | | | Refactor to create AddCompileDefinitions.
generated by cgit v0.12 at 2024-11-07 19:19:46 (GMT)