| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Provide an option to switch back to the original build system via
`-T buildsystem=1`.
Fixes: #18088
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Move this up from `cmGlobalXCodeGenerator`. It will be useful for all
generators.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Support both STRING and OBJECT_LIST types in build setting attributes and make it possible to mix them
|
|\
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |
| |
| |
| |
| |
| |
| | |
When OBJC or OBJCXX is enabled as a language, prefer that for .m and .mm
source file language selection.
Fixes: #20257
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
|/
|
|
|
| |
* Instead of `classes` use name `commonSourceFiles`.
* No need for reference when you have pointer.
|
|
|
|
| |
Update internals of various classes.
|
| |
|
| |
|
|
|
|
|
| |
Extend the `cmGlobalGenerator::SetGeneratorToolset` signature to
indicate when it is called from `cmake::build`.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
In various places `///!` was used to start a comment line. This is not valid
Doygen syntax. This patch replaces `///!` comment starts with `//!`.
|
| |
|
| |
|
|
|
|
| |
Fixes: #16136
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
This refactors a std::vector<std::string> into a class so that
we can extend the features to represent things such as multiple
chained commands in the future.
|
|
|
|
| |
Fixes: #14983, #16561
|
|
|
|
| |
Make it easy to detect use of the Xcode generator.
|
| |
|
|
|
|
|
| |
Compute an index for each target in a global ordering such that no
target comes before its dependencies.
|
|
|
|
| |
Closes: #18099
|
|
|
|
|
|
|
|
|
|
|
|
| |
Run the `clang-format.bash` script to update all our C and C++ code to a
new style defined by `.clang-format`. Use `clang-format` version 6.0.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
|
|
|
|
|
|
|
| |
While we already support `cmake --build . -- -j`, the options after `--`
are specific to the native build tool. Add new options `--parallel
[<N>]` and `-j [<N>]` to abstract this and map to the proper option
for the native build tool.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since commit v3.11.0-rc1~467^2 (VS,Xcode: Add CMakeLists.txt sources
without mutating targets, 2017-10-18) we do not add `CMakeLists.txt` to
target sources but instead generate references to them directly. This
broke projects that explicitly specify their `CMakeLists.txt` file as a
source file because the explicit entry is no longer consolidated with
the generated one.
Teach the relevant generators to avoid duplicating `CMakeLists.txt`
source references and add test cases.
Fixes: #17828
|
|
|
|
|
|
|
|
|
|
| |
* Change some functions to take `std::string` instead of
`const char*` in the following classes: `cmMakeFile`, `cmake`,
`cmCoreTryCompile`, `cmSystemTools`, `cmState`, `cmLocalGenerator`
and a few others.
* Greatly reduce using of `const char*` overloads for
`cmSystemTools::MakeDirectory` and `cmSystemTools::RelativePath`.
* Remove many redundant `c_str()` conversions throughout the code.
|
|
|
|
|
| |
Introduce method AppendCompileOptions to support
future source file property COMPILE_OPTIONS.
|
|
|
|
| |
Closes: #17431
|
| |
|
|
|
|
|
|
|
|
| |
Fix issues diagnosed by clang-tidy
- performance-unnecessary-value-param
- performance-unnecessary-copy-initialization
Signed-off-by: Matthias Maennich <matthias@maennich.net>
|
|
|
|
|
|
|
|
| |
We now require C++11 support including `override`. Drop use of
the old compatibility macro. Convert references as follows:
git grep -l CM_OVERRIDE -- '*.h' '*.hxx' '*.cxx' |
xargs sed -i 's/CM_OVERRIDE/override/g'
|
|
|
|
| |
Also remove `#include "cmConfigure.h"` from most source files.
|
|
|
|
|
|
|
|
| |
When calculating Object Library paths take a look at the
`XCODE_EMIT_EFFECTIVE_PLATFORM_NAME` property to enable builds with
different SDKs. Otherwise a hard-coded architecture could be chosen.
Fixes: #16040
|
|\
| |
| |
| |
| |
| |
| | |
01cd88c0 Xcode: Remove the top-level Sources and Resources groups
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !779
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This addresses duplicate file reference warnings from xcodebuild caused
by the same file reference being a member of both the target's group and
the top-level Resources group. Since resources are already a member of
their associated target's group the top-level Resources group isn't
strictly necessary, and removing it results in a project structure
closer to that of a current Xcode project template.
Fixes: #15272
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
Add a `HasKnownObjectFileLocation` method returning whether we know the
exact location of object files produced by the native build system.
This is true everywhere except on Xcode when an architecture placeholder
is used.
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
1d829c86 Use quotes for non-system includes
26ee9e42 CPack: drop CPack prefix for includes
5afac50f cmConfigure: Ensure separate include block in headers
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !691
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Automate with:
git grep -l '#include <cm_' -- Source \
| xargs sed -i 's/#include <\(cm_.*\)>/#include "\1"/g'
git grep -l '#include <cmsys/' -- Source \
| xargs sed -i 's/#include <\(cmsys\/.*\)>/#include "\1"/g'
git grep -l '#include <cm[A-Z]' -- Source \
| xargs sed -i 's/#include <\(cm[A-Z].*\)>/#include "\1"/g'
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make sure that `#include <cmConfigure.h>` is followed by an empty line
in header files. This is necessary to make sure that changing <> to ""
does not affect the include ordering of clang-format.
Automate with:
git grep -l '#include <cmConfigure.h>' | grep -v '.cxx$' \
| xargs sed -i '/#include <cmConfigure.h>/ { N; N; s/\n\{1,2\}/\n\n/ }'
|
| | |
|