summaryrefslogtreecommitdiffstats
path: root/Source/cmGlobalXCodeGenerator.h
Commit message (Collapse)AuthorAgeFilesLines
* Xcode: Allow bundling extensionkit extensionsRussell Greene2022-11-181-1/+3
| | | | Fixes: #24150
* Refactor: `cmGlobalGeneratorFactory::GetDocumentation` returns entryAlex Turbov2022-11-171-2/+2
| | | | | | | | | | Before, a documentation entry was in/out parameter. Now it's a normal return value. This also makes possible to eliminate defaulted default ctor for `cmDocumentationEntry` for C++ 11. Also, simplify `cmake::AppendGlobalGeneratorsDocumentation()`.
* Xcode: Put object files in a place that Xcode cleansBrad King2022-10-281-0/+4
| | | | | | | | | Since commit dc5fc898f6 (Xcode: Set object file locations using TARGET_TEMP_DIR, 2022-09-29, v3.25.0-rc1~64^2~1), `xcodebuild clean` does not remove the object files in our explicit `TARGET_TEMP_DIR` because it is not under the `SYMROOT`. Put it there. Fixes: #24096
* Xcode: Set object file locations using TARGET_TEMP_DIRBrad King2022-09-291-5/+0
| | | | | | This avoids relying on `SYMROOT` to locate the object files. Issue: #22550
* cmTarget: Add `HasKnownObjectFileLocation()` shorthandHyper Nova Sun2022-04-111-1/+2
| | | | | | | | Allow `cmGlobalGenerator`s to decide `HasKnownObjectFileLocation()` per given `cmTarget` - `cmGlobalGenerator::HasKnownObjectFileLocation()` now takes an optional `cmGeneratorTarget` - `cmTarget::HasKnownObjectFileLocation()` added as a shorthand
* xcode: add support for xcconfig filesGregor Jasny2022-04-031-0/+6
| | | | Fixes: #18420
* cmGlobalGenerator: Add helper to split framework pathMarc Chevrier2022-02-131-0/+2
| | | | | cmComputeLinkInformation and cmGlobalXCodeGenerator now rely on this method to handle framework paths.
* cmBuildOptions: Split build arguments into separate object.Carsten Rudolph2022-01-221-1/+2
|
* Source: Fix IWYU warnings in Xcode generatorsNAKAMURA Takumi2021-11-161-0/+2
|
* Xcode: Add embedded plugins optionGusts Kaksis2021-11-101-0/+1
|
* Restore honoring CMAKE_GENERATOR_INSTANCE in toolchain fileBrad King2021-10-201-5/+0
| | | | | | | | | | | | | | | Revert the changes from commit d5b5c19278 (cmGlobalGenerator: FindMakeProgram() before CMakeDetermineSystem, 2020-06-15, v3.19.0-rc1~619^2~3) and commit ef91fb02f3 (cmGlobalGenerator: FindMakeProgram() at a generator-specific time, 2020-11-23, v3.19.1~2^2). We must delay selecting the location of MSBuild until after an instance of Visual Studio has been selected. It is now safe to revert the ordering because the motivating use case (sysroot detection in Platform/Android-Determine) has been implemented another way. Fixes: #22782
* Rename cmProp in cmValueMarc Chevrier2021-09-211-1/+1
|
* cmGlobalGenerator::PrintCompilerAdvice: use cmProp as augmentMarc Chevrier2021-09-191-1/+1
|
* cmGlobalXCodeGenerator: Simplify relative path conversion under project rootBrad King2021-05-121-2/+1
|
* Merge topic 'xcode_app_extensions'Brad King2021-04-261-0/+13
|\ | | | | | | | | | | | | | | eb5e33ba47 Xcode: Add support for embedding app extensions f62a2bf44f Tests: Factor out XcodeProject-Embed check function findAttribute() Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5934
| * Xcode: Add support for embedding app extensionsAlexander Akhundzhanov2021-04-221-0/+13
| | | | | | | | Co-Authored-By: Craig Scott <craig.scott@crascit.com>
* | Xcode: Add support of DEPFILE for add_custom_command, part 2Marc Chevrier2021-04-171-5/+4
| | | | | | | | | | | | This MR extend the support of 'DEPFILE' to buildsystem version 1. Issue: #20286
* | Xcode: Add support of DEPFILE for add_custom_commandMarc Chevrier2021-04-151-0/+13
|/ | | | Issue: #20286
* Merge topic 'xcode-object-ids'Brad King2021-01-081-2/+7
|\ | | | | | | | | | | | | | | | | b8b6573db8 Xcode: Use deterministic object ids for script build phases 2892228dc9 cmGlobalXCodeGenerator: Add infrastructure for deterministic object ids d250b67722 cmGlobalXCodeGenerator: Adopt pbxproj object id generation Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5671
| * Xcode: Use deterministic object ids for script build phasesBrad King2021-01-061-1/+2
| | | | | | | | | | | | | | | | | | | | The Xcode "new build system" only considers a script build phase up to date if it has run before, even if outputs are newer than inputs. Use a deterministic object id for script build phases associated with custom commands so that they do not need to re-run after CMake re-generates the project. Fixes: #21669
| * cmGlobalXCodeGenerator: Add infrastructure for deterministic object idsBrad King2021-01-061-2/+5
| |
| * cmGlobalXCodeGenerator: Adopt pbxproj object id generationBrad King2021-01-061-0/+1
| |
* | Xcode: Generalize inheritance of project-level search pathsBrad King2020-12-221-0/+2
| | | | | | | | | | | | | | | | | | Generalize the change from commit bffb17be3d (Xcode: Inherit target library and framework search paths from project, 2020-11-04, v3.19.0-rc3~4^2) to apply to framework and other kinds of search paths added either for include directories or for linking. Issue: #21617
* | cmGlobalXCodeGenerator: Factor out helper to append attributeBrad King2020-12-211-0/+3
| |
* | Xcode: add support for embedding frameworksGusts Kaksis2020-11-281-0/+3
|/ | | | | | This commit also prepares for embedding things other than frameworks. In the future, we may want to embed resources and other types supported by Xcode, so the target properties have been documented in a way that clearly signals the future intent.
* cmGlobalGenerator: FindMakeProgram() at a generator-specific timeKyle Edwards2020-11-231-0/+5
| | | | | | | | | | d5b5c192 moved FindMakeProgram() to an earlier time, which resulted in CMAKE_MAKE_PROGRAM not being read from the toolchain file. Change it to only call FindMakeProgram() early in the specific cases of Visual Studio and Xcode, and restore the old behavior for all other generators. Fixes: #21486
* Xcode: Remove remnants of ancient XCODE_DEPEND_HELPER utility targetBrad King2020-09-241-1/+1
| | | | | | The target has not been generated since commit d92d51429e (BUG: fix for bug 6193, fix xcode depend helper, 2008-01-10, v2.6.0~553). Remove it from the list of special targets.
* Xcode: Switch to the "new build system" for Xcode 12 and aboveBrad King2020-09-181-0/+16
| | | | | | | Provide an option to switch back to the original build system via `-T buildsystem=1`. Fixes: #18088
* Xcode: Add option to specify build system variantBrad King2020-09-181-0/+11
| | | | | | Extend the `-T <toolset>` option to support a `buildsystem=` field with the Xcode generator. Add a `CMAKE_XCODE_BUILD_SYSTEM` variable to inform project code about the selected build system variant.
* Xcode: Clarify name of legacy run script build phase helperBrad King2020-09-181-3/+3
|
* cmGlobalGenerator: Compute a global target ordering respecting dependenciesBrad King2020-09-041-3/+0
| | | | | Move this up from `cmGlobalXCodeGenerator`. It will be useful for all generators.
* Modernize: Use #pragma once in all header filesKitware Robot2020-09-031-4/+1
| | | | | | | | | | | | | | | | #pragma once is a widely supported compiler pragma, even though it is not part of the C++ standard. Many of the issues keeping #pragma once from being standardized (distributed filesystems, build farms, hard links, etc.) do not apply to CMake - it is easy to build CMake on a single machine. CMake also does not install any header files which can be consumed by other projects (though cmCPluginAPI.h has been deliberately omitted from this conversion in case anyone is still using it.) Finally, #pragma once has been required to build CMake since at least August 2017 (7f29bbe6 enabled server mode unconditionally, which had been using #pragma once since September 2016 (b13d3e0d)). The fact that we now require C++11 filters out old compilers, and it is unlikely that there is a compiler which supports C++11 but does not support #pragma once.
* Xcode: Avoid unnecessary duplication of custom commands across targetsBrad King2020-09-011-0/+2
| | | | | | | | | | | | | Do not attach a custom command to a target if it is already attached to one of the target's dependencies. The command's output will be available by the time the target needs it because the dependency containing the command will have already been built. Since commit fb45559e09 (Xcode: Process targets in depth-first order during generation, 2018-07-19, v3.13.0-rc1~293^2) we generate a target only after generating its dependencies. Therefore when visiting the custom commands in a target, we can assume that custom commands in its dependencies have already been visited.
* Xcode: Refactor build setting append code and attribute getter namingGusts Kaksis2020-08-281-2/+2
| | | | Support both STRING and OBJECT_LIST types in build setting attributes and make it possible to mix them
* Merge topic 'xcode-native-arch'Craig Scott2020-07-211-0/+2
|\ | | | | | | | | | | | | | | 26673bf480 Xcode: Explicitly specify default native architecture on macOS ce624cfbd4 cmGlobalXCodeGenerator: Save CMAKE_SYSTEM_NAME in member Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5023
| * cmGlobalXCodeGenerator: Save CMAKE_SYSTEM_NAME in memberBrad King2020-07-161-0/+2
| |
* | Xcode: Use "Link Binary With Libraries" to link any libraryGusts Kaksis2020-07-141-4/+6
| | | | | | | | | | | | | | | | | | | | Add external libraries as fileRefs to Xcode project and add those references to Link Binary With Libraries build phase. This allows linking .a, .o, .dylib, .framework and .tbd libraries through "Link Binary With Libraries" build phase, as opposed to `OTHER_LINKER_FLAGS`. This improves on the approach added by commit 58c05e1c73 (Xcode: Use "Link Binary With Libraries" build phase when possible, 2020-06-12).
* | Xcode: Fix LANGUAGE property on .m/.mm filesHarry Mallon2020-07-031-0/+1
| | | | | | | | | | | | | | When OBJC or OBJCXX is enabled as a language, prefer that for .m and .mm source file language selection. Fixes: #20257
* | Xcode: Use "Link Binary With Libraries" build phase when possibleGusts Kaksis2020-06-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Try linking all target linked libraries through frameworks build phase instead of linker flags, thus letting Xcode manage build product paths correctly. Prevent adding duplicate entries to "Link Binary With Libraries" build phase. Add check for configuration-dependent linking - in case the library is not present in all configurations revert back to linker flags which are per-configuration. This does change the order of libraries linked, but that does not seem to matter for Apple linkers invoked by Xcode, even for static libraries. The linker will go back and re-consider a static library from earlier on the link line when more symbols from its objects are needed. Fixes: #14185
* | Xcode: Refactor generator variable names and typesGusts Kaksis2020-06-151-1/+1
|/ | | | | * Instead of `classes` use name `commonSourceFiles`. * No need for reference when you have pointer.
* Modernize memory managementMarc Chevrier2020-03-051-2/+6
| | | | Update internals of various classes.
* GlobalGenerator family: modernize memory managementMarc Chevrier2020-01-071-1/+1
|
* cmLocalGenerator: modernize memory managementMarc Chevrier2019-12-091-1/+3
|
* cmake: Teach --build mode to load CMAKE_GENERATOR_TOOLSETAlexander Boczar2019-10-151-1/+2
| | | | | Extend the `cmGlobalGenerator::SetGeneratorToolset` signature to indicate when it is called from `cmake::build`.
* clang-tidy: Resolve performance-unnecessary-value-param diagnosticsBrad King2019-09-091-7/+5
| | | | | | Fix diagnostics that appear on macOS with clang-tidy-8. Suppress cases where we intentionally take an argument by value to let the caller choose whether to copy or move.
* Fix invalid ///! doxygen comment line startsSebastian Holtermann2019-03-311-4/+4
| | | | | In various places `///!` was used to start a comment line. This is not valid Doygen syntax. This patch replaces `///!` comment starts with `//!`.
* Xcode: Create Xcode schemes per targetHarry Mallon2019-03-211-3/+4
|
* cmGlobalXCodeGenerator: Prefer std::string over char*Gregor Jasny2019-03-171-2/+2
|
* cmake: Teach --build mode to support multiple targetsBartosz Kosiorek2019-03-051-9/+6
| | | | Fixes: #16136
* Xcode: Place object library artifacts outside Objects-normal directoryBrad King2019-01-301-3/+4
| | | | | | | | | | | The `CONFIGURATION_BUILD_DIR` value in the Xcode project file specifies where to place the library artifact. For object libraries we've used the `Objects-normal` directory to hide away the `.a` that we otherwise cannot stop Xcode from producing. The parent of this directory is also specific to the target and does not vary with Xcode's sanitizer features, so move the artifact there. Issue: #16289
generated by cgit v0.12 at 2024-11-11 11:45:08 (GMT)