- 04 Jun, 2014 1 commit
-
-
Brad King authored
The latter matches with CMAKE_GENERATOR_TOOLSET better.
-
- 15 May, 2014 2 commits
-
-
Brad King authored
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.
-
Brad King authored
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.
-
- 07 May, 2014 1 commit
-
-
Ben Boeckel authored
-
- 02 Apr, 2014 3 commits
-
-
Stephen Kelly authored
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.
-
Stephen Kelly authored
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.
-
Stephen Kelly authored
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.
-
- 31 Mar, 2014 3 commits
-
-
Stephen Kelly authored
Avoid calling it too early when cmGeneratorTarget instances don't yet exist.
-
Stephen Kelly authored
Continue to call GetOrCreateSource where necessary to create cmSourceFile objects which have the GENERATED attribute set.
-
Stephen Kelly authored
Add a new AddSource method for future use.
-
- 15 Mar, 2014 1 commit
-
-
Stephen Kelly authored
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.
-
- 13 Mar, 2014 3 commits
-
-
Stephen Kelly authored
Implement it in the local generators and use it in the global generators.
-
Stephen Kelly authored
Some of them will be used with other APIs which require value_type to be cmSourceFile const*.
-
Stephen Kelly authored
Make it public for future external calls.
-
- 12 Mar, 2014 3 commits
-
-
Brad King authored
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.
-
Brad King authored
Make the multiple output pair map more local. Generate it where we have the current configuration available.
-
Brad King authored
-
- 08 Mar, 2014 10 commits
-
-
-
-
-
-
-
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.
-
-
-
-
It gets turned into a string anyways, so pass them in.
-
- 24 Feb, 2014 1 commit
-
-
Stephen Kelly authored
-
- 03 Feb, 2014 1 commit
-
-
Clinton Stimpson authored
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.
-
- 22 Jan, 2014 1 commit
-
-
Stephen Kelly authored
Return a pointer instead of a reference. This allows making the accessor const with the least impact.
-
- 16 Jan, 2014 2 commits
-
-
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.
-
Variable 'ext' already checked for equality to "xib" so remove the branch that will never be executed.
-
- 09 Jan, 2014 2 commits
-
-
Stephen Kelly authored
In a future patch, this will also be populated with extra sources from the linked dependencies.
-
Stephen Kelly authored
These methods and others will be able to get a config parameter later to implement the INTERFACE_SOURCES feature.
-
- 07 Jan, 2014 2 commits
-
-
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'.
-
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'.
-
- 06 Jan, 2014 1 commit
-
-
Stephen Kelly authored
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.
-
- 11 Dec, 2013 1 commit
-
-
Stephen Kelly authored
-
- 02 Dec, 2013 1 commit
-
-
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.
-
- 18 Nov, 2013 1 commit
-
-
Brad King authored
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.
-