CMake merge requestshttps://gitlab.kitware.com/cmake/cmake/-/merge_requests2018-02-21T10:56:26-05:00https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1712Ninja: Use as dependency file <objectDir/SourceName>.d if needed.2018-02-21T10:56:26-05:00Claus KleinNinja: Use as dependency file <objectDir/SourceName>.d if needed.Use a dependency file name like `<objectDir/SourceName>.d` if needed
==============================================================================
Motivation
==========
gcov, lcov
----------
I have a particular problem wit...Use a dependency file name like `<objectDir/SourceName>.d` if needed
==============================================================================
Motivation
==========
gcov, lcov
----------
I have a particular problem with the cmake generated output file naming
conventions (like myfile.cpp.o, myfile.cpp.gcno, ....).
These naming conventions creating trouble for me to run `gcov *.cpp` properly
with my -o /objdir option (**I had to copy them in the same directory without
the .ccp extensions every time!**).
see https://cmake.org/pipermail/cmake/2012-August/051628.html
Ancient cross compiler
---------------------
The C compiler test fails because CMake insists on createing
testCCompiler.c.r30 and there doesn't seem to be way to tell it to not
include the source file name extension (here: .c) into the object file name.
However, the linker takes the first dot as extension (I know that this is
horribly broken) and only takes files that have ".r30" as extension. ".c.r30"
is an illegal extension.
see https://cmake.org/pipermail/cmake/2008-April/021057.html
More proprietary compilers
--------------------------
Ninja generator sets the name to objectpath.d:
cmGlobalNinjaGenerator::EncodeDepfileSpace(objectFileName + ".d");
WindRiver sets the dependency file name to objectDir/SourceName.d, so the `".obj"`
in `"DEP_FILE = path/BaseName.c.obj.d"` must be renamed!
see https://cmake.org/pipermail/cmake/2014-October/058963.html
GHS compiler too
-----------------
Wenn using the Ninja generator to build with GHS compiler for Integrity targets,
we have the same problem. We can NOT control the name of the generated
dependency ".d" file while compile step!
"DEP_FILE = path/BaseName.d" **has to be used!**
see https://cmake.org/pipermail/cmake-developers/2018-January/030532.html
Solution
========
If we really want to avoid the extension we can set the *undocumented internal
implementation detail* variable:
set(CMAKE_C_DEPFILE_EXTENSION_REPLACE 1)
set(CMAKE_CXX_DEPFILE_EXTENSION_REPLACE 1)
some time after the project() command call that enables the C and CXX
languages.
Patch needed
------------
Change the Nina generator:
file: Source/cmNinjaTargetGenerator.cxx
function: void cmNinjaTargetGenerator::WriteObjectBuildStatement(...)
// ...
```c++
if (!this->NeedDepTypeMSVC(language)) {
bool replaceExt(false);
if (!language.empty()) {
std::string repVar = "CMAKE_";
repVar += language;
repVar += "_DEPFILE_EXTENSION_REPLACE";
replaceExt = this->Makefile->IsOn(repVar);
}
if (!replaceExt) {
// use original code
vars["DEP_FILE"] = this->GetLocalGenerator()->ConvertToOutputFormat(
objectFileName + ".d", cmOutputConverter::SHELL);
} else {
// Replace the original source file extension with the
// depend file extension.
std::string dependFileName = cmSystemTools::GetFilenameWithoutExtension(
objectFileName) + ".d";
vars["DEP_FILE"] = this->GetLocalGenerator()->ConvertToOutputFormat(
objectFileDir + "/" + dependFileName, cmOutputConverter::SHELL);
}
}
```
Caveat
======
As the variables are *internal details* this will not be guaranteed to work in
the future!
Question
========
Is it possible to make the *internal `CMAKE_<LANG>_OUTPUT_EXTENSION_REPLACE`
option* public and support it in future CMake releases including my patch?
---
Topic-rename: ninja-depfile-name
Superseded-by: !1781 3.12.0https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1745FindDoxygen: Improve `doxygen_add_docs`2019-08-22T18:39:49-04:00Alex TurbovFindDoxygen: Improve `doxygen_add_docs`* `doxygen_add_docs` now accepts targets as documentation input.
And for this case would append its sources to the `DOXYGEN_INPUT` list.
It is also possible to filter what sources should count using a list
of regular expressions...* `doxygen_add_docs` now accepts targets as documentation input.
And for this case would append its sources to the `DOXYGEN_INPUT` list.
It is also possible to filter what sources should count using a list
of regular expressions which are applied to all or individual targets;
* When `DOXYGEN_INPUT` consists of files only, it is possible to use
`add_custom_output` instead of `add_custom_target`.
so documentation gets rebuild only when something has really changed;
* There is an additional option `ALL` could be set to make added target
to be executed by default build.
Topic-rename: FindDoxygen-improve-doxygen_add_docs
3.12.0Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/2009WIP: CPack: Add CPackExternal module2018-04-27T12:20:45-04:00Kyle EdwardsWIP: CPack: Add CPackExternal moduleThis module can be used by external packaging software to gather
information from inside CPack and carry out tasks that CPack would
normally do.
This is still a WIP and will evolve as my needs for dh-cmake change.This module can be used by external packaging software to gather
information from inside CPack and carry out tasks that CPack would
normally do.
This is still a WIP and will evolve as my needs for dh-cmake change.3.12.0https://gitlab.kitware.com/cmake/cmake/-/merge_requests/2021cmVisualStudio10TargetGenerator: XML refactoring (continued)2018-05-02T11:19:40-04:00vvs31415cmVisualStudio10TargetGenerator: XML refactoring (continued)3.12.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/2106WIP: Autogen: Use intermediate custom command for rcc wrapper generation2018-05-30T11:46:55-04:00Sebastian HoltermannWIP: Autogen: Use intermediate custom command for rcc wrapper generationFor multi configuration generators this adds a dedicated custom command
to generate the rcc output wrapper file. The file used to be generated by
the `cmake -E cmake_autorcc` command which now generates the actual rcc
output file only...For multi configuration generators this adds a dedicated custom command
to generate the rcc output wrapper file. The file used to be generated by
the `cmake -E cmake_autorcc` command which now generates the actual rcc
output file only. The motivation is to allow per configuration dependencies
of the wrapper file (custom command).
Fixes: #18006
3.12.0