CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-28T10:31:42-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/25834--graphviz=deps/d does not create the directory2024-03-28T10:31:42-04:00Jan Dorniak--graphviz=deps/d does not create the directoryWhen calling `cmake --graphviz=deps/d` I'd expect CMake to create a directory named `deps` and create the files in there. Instead, I get errors about the directory not existing. At a minimum, it should error out when given a path it can ...When calling `cmake --graphviz=deps/d` I'd expect CMake to create a directory named `deps` and create the files in there. Instead, I get errors about the directory not existing. At a minimum, it should error out when given a path it can not handle (no slashes allowed as an argument to `--graphviz`). Best though would be for CMake to just create the directory.https://gitlab.kitware.com/cmake/cmake/-/issues/25833Automoc uses the Debug version of moc2024-03-28T08:47:38-04:00Andreas HaferburgAutomoc uses the Debug version of mocThis is a follow up to https://gitlab.kitware.com/cmake/cmake/-/issues/25707.
I'm not sure if/how much code I need to post here.
We use Conan to add Debug and Release builds of Qt 6.6.2.
`find_package(Qt6 CONFIG REQUIRED COMPONENTS Co...This is a follow up to https://gitlab.kitware.com/cmake/cmake/-/issues/25707.
I'm not sure if/how much code I need to post here.
We use Conan to add Debug and Release builds of Qt 6.6.2.
`find_package(Qt6 CONFIG REQUIRED COMPONENTS Core Widgets)`
The AutogenInfo.json points to the Debug version of moc.exe.
![image](/uploads/882a8929978f03f9f02eda68fa3ca4f8/image.png)
![image](/uploads/f5348f5f6b5110ab5f3515f86de26545/image.png)
(There's a .pdb file next to it, and we don't build Release with symbols.)
The [documentation of AUTOMOC_EXECUTABLE](https://cmake.org/cmake/help/latest/prop_tgt/AUTOMOC_EXECUTABLE.html#prop_tgt:AUTOMOC_EXECUTABLE) says
> Usually this property does not need to be set. Only consider this property if auto-detection of moc can not work -- e.g. because you are building the moc binary as part of your project.https://gitlab.kitware.com/cmake/cmake/-/issues/25832CPack: Calling `cpack --help-variable-list` lists too few `CPACK_*` variables2024-03-28T08:13:00-04:00Deniz BahadirCPack: Calling `cpack --help-variable-list` lists too few `CPACK_*` variablesWhen running `cpack --help-variable-list` I get a large list of variables, however the one that are prefixed with `CPACK_` is quite small:
```
CPACK_ABSOLUTE_DESTINATION_FILES
CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY
CPACK_CUSTOM_INST...When running `cpack --help-variable-list` I get a large list of variables, however the one that are prefixed with `CPACK_` is quite small:
```
CPACK_ABSOLUTE_DESTINATION_FILES
CPACK_COMPONENT_INCLUDE_TOPLEVEL_DIRECTORY
CPACK_CUSTOM_INSTALL_VARIABLES
CPACK_ERROR_ON_ABSOLUTE_INSTALL_DESTINATION
CPACK_INCLUDE_TOPLEVEL_DIRECTORY
CPACK_INSTALL_DEFAULT_DIRECTORY_PERMISSIONS
CPACK_PACKAGING_INSTALL_PREFIX
CPACK_SET_DESTDIR
CPACK_WARN_ON_ABSOLUTE_INSTALL_DESTINATION
```
I would have expected a lot more variables listed there.
Especially, because the generated `CPackConfig.cmake` file has the following statement at the top:
```
# This file will be configured to contain variables for CPack. These variables
# should be set in the CMake list file of the project before CPack module is
# included. The list of available CPACK_xxx variables and their associated
# documentation may be obtained using
# cpack --help-variable-list
#
# Some variables are common to all generators (e.g. CPACK_PACKAGE_NAME)
# and some are specific to a generator
# (e.g. CPACK_NSIS_EXTRA_INSTALL_COMMANDS). The generator specific variables
# usually begin with CPACK_<GENNAME>_xxxx.
```https://gitlab.kitware.com/cmake/cmake/-/issues/25831Support hard-links for CMAKE_INSTALL_MODE2024-03-28T10:06:45-04:00Andreas RinglstetterSupport hard-links for CMAKE_INSTALL_MODE<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
# What's wrong with Symlinks?
While the symlink support in `CMAKE_INSTALL_MODE` is great for local development (turning installs "for free"), it's actually quite troublesome when you try to use this for an actual installation or in a CI/CD context where the installed package is typically supposed to out-last the corresponding build folder.
And then there is also the huge catch that with any form of package system chained outside of the CMake install step, symlinks usually have a special semantic and usually end up inside a package. After all - the package system can't really distinguish between a symlink that's supposed to be targeting outside of the package and one that shouldn't have!
Then there's also yet another elephant in the room: Whatever software attempts to work with the installed components needs to be symlink-compatible to function at all. That's not a given! Especially under Windows, the support for "Vista style symlinks" - `.symlink` files - is pretty much non-existent.
# What else to use?
Now, there are plenty of reasons why symlinks are actually a pretty bad idea to use. But let's take a look at the alternatives, what works and what wouldn't:
## Linux
For Linux systems, we only have one alternative - true hardlinks. Any software observing the CMake install prefix is agnostic to it even being a hardlink. There's merely the catch that hardlinks - unlike symlinks - can only reside in the same file system.
`cp -lrP` e.g. behaves exactly as you expect - you get a hard link for files, and it behaves exactly as it should. Directories are ***not*** hard-linked, only the contents. So this prevents e.g. temporary files from the install-prefix from back-propagating into the build or source tree!
There's also a couple of very nice side effects, such as that when hard-link a relative soft-link, it's effectively pointing to the correct *new* relative location. (Also check #14609 - neither install nor the copy commands in CMake correctly deal with relative symlinks in source directories at all!)
Hardlinks do not require elevated permissions to create. They just work. And if they are not supported by the file system, a flat copy simply behaves exactly as you'd expect too. They do share permissions in the file system with the original file - but that's more of a feature than an issue as well.
## Windows
For Windows systems, there's junctions and hardlinks. The first one unfortunately only works for directories, but otherwise behaves more like a soft-link in Linux (it can turn invalid if the target is gone, and turn valid again later). Hard-links are only for files. But ***both*** are usually entirely transparent to software accessing the file system - neither a junction nor a hard-link behaves like a special type of file as it would had in Linux!
In terms of permissions required, we are in a bit of a ditch here. Hard links require administrator privileges, junctions don't. But since junctions can't be used with files, you can't use them to make a directory structure.
Even though the use of hard links requires elevated privileges, I would still recommend to use ***only*** hardlinks and avoid the use of junctions (even when asked to install directories!) due to the unexpected behavior of junctions to turn invalid. And to likewise mimic the behavior of a `cp -lrP`, so directories are ***copied*** and only files are ***linked***.
In any case - `.symlink` files as introduced in CMake 3.22 are pretty much the worst possible solution, and don't work more often than they would work.https://gitlab.kitware.com/cmake/cmake/-/issues/25830FindBoost: Wrong dependency for Boost.Log2024-03-28T11:01:50-04:00joaquintidesFindBoost: Wrong dependency for Boost.LogFindBoost.cmake lists `log_setup` as a dependency for Boost.Log, for instance here:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Modules/FindBoost.cmake#L1374
This dependency is not correct and should be removed. Actually, `lo...FindBoost.cmake lists `log_setup` as a dependency for Boost.Log, for instance here:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Modules/FindBoost.cmake#L1374
This dependency is not correct and should be removed. Actually, `log_setup` depends on Boost.Log, as shown in the Boost-provided CML:
https://github.com/boostorg/log/blob/boost-1.84.0/CMakeLists.txt#L546-L561
Additionally, it would be convenient to have a target `log_setup` defined as indicated in the aforementioned CML.
Thank youhttps://gitlab.kitware.com/cmake/cmake/-/issues/25829CMP0159 warnings in cmake's Modules when tracing2024-03-27T10:49:45-04:00alcroitoCMP0159 warnings in cmake's Modules when tracinghttps://gitlab.kitware.com/cmake/cmake/-/merge_requests/9124 added a new policy that does not warn by default, unless tracing is enabled.
CMake's own Find modules contain many `file(STRINGS)` calls which then show the policy warning whe...https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9124 added a new policy that does not warn by default, unless tracing is enabled.
CMake's own Find modules contain many `file(STRINGS)` calls which then show the policy warning when tracing is enabled in a user project.
I think all those need to be handled with blocks like
```cmake
cmake_policy(PUSH)
if(POLICY CMP0159)
cmake_policy(SET CMP0159 NEW)
endif()
file(STRINGS ...)
cmake_policy(POP)
```Juan RamosJuan Ramoshttps://gitlab.kitware.com/cmake/cmake/-/issues/25828cxxmodules: CMP0155 Ninja generator on windows might generate invalid filenam...2024-03-26T13:38:13-04:00Nils Gladitzcxxmodules: CMP0155 Ninja generator on windows might generate invalid filenames with colonsGiven the following reduced, self-contained testcase:
```CMake
cmake_minimum_required(VERSION 3.28)
project(Foo CXX)
set(CMAKE_CXX_STANDARD 20)
file(WRITE Foo.cpp "")
add_library(Foo SHARED Foo.cpp)
set_property(TARGET Foo PROPERTY...Given the following reduced, self-contained testcase:
```CMake
cmake_minimum_required(VERSION 3.28)
project(Foo CXX)
set(CMAKE_CXX_STANDARD 20)
file(WRITE Foo.cpp "")
add_library(Foo SHARED Foo.cpp)
set_property(TARGET Foo PROPERTY EXPORT_NAME "Foo::Foo")
install(TARGETS Foo EXPORT Default)
install(EXPORT Default DESTINATION cmake)
```
I get the following example output / error:
```
[2/4] Generating CXX dyndep file CMakeFiles\Foo.dir\CXX.dd
CMake Error: Cannot open file for write: C:/Users/n.gladitz/Desktop/testcase/build/CMakeFiles/Export/272ceadb8458515b2ae4b5630a6029cc/target-Foo::Foo-Debug.cmake.tmp94446
CMake Error: : System Error: Invalid argument
```
There is no error when I lower my minimum required version back to 3.27.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25827CMakePackageConfigHelpers' configure_package_config_file() interferes with pa...2024-03-26T05:28:07-04:00Tim KauneCMakePackageConfigHelpers' configure_package_config_file() interferes with parent packageWhen a project uses the `configure_package_config_file()` macro from the `CMakePackageConfigHelpers` module to configure its package config file, there is a variable called `PACKAGE_PREFIX_DIR` in the `@PACKAGE_INIT@` block. This is a ga...When a project uses the `configure_package_config_file()` macro from the `CMakePackageConfigHelpers` module to configure its package config file, there is a variable called `PACKAGE_PREFIX_DIR` in the `@PACKAGE_INIT@` block. This is a garden-variety local variable.
The problem arises, when the project includes a child dependency via `find_package()`/`find_dependency()` in the same package config file and the child dependency's package config file has also been created with `configure_package_config_file()`, but is installed in a *different install prefix*!
`find_package()` [modifies variables in the parent scope](https://discourse.cmake.org/t/find-package-not-working-from-a-subdirectory/4632/2). The child dependency also has a variable `PACKAGE_PREFIX_DIR` from the `@PACKAGE_INIT@` block, but with a different value. It overwrites the `PACKAGE_PREFIX_DIR` in the parent project. If the parent project now uses `PACKAGE_PREFIX_DIR` after this `find_package()` call (via `@PACKAGE_<variable name>@`), the variable has a wrong value and paths break. This is unexpected behavior for the author of the parent package (at least, it was for me), who should not be required to know about the internals of the included dependency.
Can't the `PACKAGE_PREFIX_DIR` variable be prefixed with the package name or something? That would be an easy fix opaque to the user.https://gitlab.kitware.com/cmake/cmake/-/issues/25826How to extract constant strings from object files in a cmake script?2024-03-26T12:54:49-04:00MaartenHow to extract constant strings from object files in a cmake script?Detecting features often requires a chain of `check_cxx_source_compiles`, which is slow on some platforms (MSVC/Windows).
It would be interesting to combine multiple checks and encode these in constant strings that are embedded in the co...Detecting features often requires a chain of `check_cxx_source_compiles`, which is slow on some platforms (MSVC/Windows).
It would be interesting to combine multiple checks and encode these in constant strings that are embedded in the compiled object file or executable.
As an example, [this CMake script](/uploads/263366b0cc579ed137dc89e14f9bbb60/CMakeLists.txt) detects the CPU architecture using a chain of `check_c_source_compiles`s.
The number of checks grows linearly by the number of supported architectures, or checks that need to be done.
I think it would be useful for CMake to do these checks "in parallel" by constructing const string literals that are greppable.
As an example, [this c source](/uploads/6228ea16973f93780bd5f2d01028a533/detect.c) detects the compiler target architecture, and also shows example usage for other tests.
Compiling this source, and running `strings a.out | grep INFO` gives an output that can be easily post processed for CMake.
```
INFO[ARCH=X64]
INFO[STDATOMIC=YES]
INFO[SYS_STAT_H=YES]
```
Compiling this single source is considerably faster than test compiling 3 (or more) sources in series.
C++ experts can probably improve on this by using SFINAE, templates and other magic.
I hope these examples are sufficient motivation to add support for extracting strings from compiled objects and/or executables in cmake scripts.https://gitlab.kitware.com/cmake/cmake/-/issues/25825CMake build with `--parallel` all child run on fist CPU/core2024-03-27T08:09:58-04:00Alex TurbovCMake build with `--parallel` all child run on fist CPU/coreSince about 9 months ago, I've been faced with a very annoying bug in CMake :disappointed:
When I use `cmake --build . -jN` it forks the requested amount of child processes but all of them are bound to the first CPU/core:
![top](/uploa...Since about 9 months ago, I've been faced with a very annoying bug in CMake :disappointed:
When I use `cmake --build . -jN` it forks the requested amount of child processes but all of them are bound to the first CPU/core:
![top](/uploads/f298bd6c16ec8f4f1e0d6595dd0bd791/top.png)
![top-tree](/uploads/21c5f20be4f56fc760449a556443dfde/top-tree.png)
However, if I run an underlaid build system directly everything scheduled correctly, and can use other CPUs:
![top-tree-ninja6](/uploads/0a5e222c201e017ef75c86505fe99488/top-tree-ninja6.png)https://gitlab.kitware.com/cmake/cmake/-/issues/25824CPACK_STRIP_FILES has no effect with relative CPACK_PACKAGING_INSTALL_PREFIX ...2024-03-25T14:24:56-04:00seemoritzCPACK_STRIP_FILES has no effect with relative CPACK_PACKAGING_INSTALL_PREFIX pathI use CPack to create a .deb package and noticed that stripping of binaries did not work in one project, but it did in another.
After a bit of testing I was able to reduce the change in behaviour to one setting:
CPACK_PACKAGING_INSTALL_P...I use CPack to create a .deb package and noticed that stripping of binaries did not work in one project, but it did in another.
After a bit of testing I was able to reduce the change in behaviour to one setting:
CPACK_PACKAGING_INSTALL_PREFIX being set to a relative path (or install(... DESTINATION relative_path), without the prefix).
Example CMakeLists.txt file:
```cmake_minimum_required(VERSION 3.16)
project(Foo VERSION 1.0.0)
add_executable(foo main.cpp)
set(CPACK_GENERATOR "DEB")
set(CPACK_STRIP_FILES TRUE)
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_PACKAGE_NAME "foo")
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "foo")
set(CPACK_DEBIAN_PACKAGE_DEPENDS "None")
# relative path: this breaks the stripping step
set(CPACK_PACKAGING_INSTALL_PREFIX "opt/foo")
# absolute path: with this the stripping works fine
#set(CPACK_PACKAGING_INSTALL_PREFIX "/opt/foo")
include(CPack)
install(TARGETS foo)
```
with main.cpp containing any valid C++ program.
Now setting CPACK_PACKAGING_INSTALL_PREFIX to a relative path was an oversight and not intentional. However since the rest of the build worked -- the resulting .deb package installed all files to the correct locations -- I did not notice this and was confused, why the stripping of the binary did not work.https://gitlab.kitware.com/cmake/cmake/-/issues/25823CMake Error(s): Option to print whole message on one line like gcc -fmessage-...2024-03-25T14:24:14-04:00Agostino SarubboCMake Error(s): Option to print whole message on one line like gcc -fmessage-length=0Hello,
by doing automated tests on opensource software I noticed, for example, that in most cases when a c/c++ application fails to build, the equivalent of `$( cat $BUILD_LOG | grep "error:" | head -1)` gives the exact error.
When you ...Hello,
by doing automated tests on opensource software I noticed, for example, that in most cases when a c/c++ application fails to build, the equivalent of `$( cat $BUILD_LOG | grep "error:" | head -1)` gives the exact error.
When you use `-fmessage-length=0` you are sure that everything is in that line.
When something fails during configuration, CMake does not print everything in one lineand it is a bit difficult find the error with regexp. Is there something like `-fmessage-length=0` for cmake?
If not, is something you accept as a feature request? maybe print error in one line if a CMAKE_* variable is exported.
Thankshttps://gitlab.kitware.com/cmake/cmake/-/issues/25821FindMPI.cmake Configuration Error with Compiler ID Checks2024-03-25T14:10:58-04:00Michael RedentiFindMPI.cmake Configuration Error with Compiler ID ChecksEncountered an issue in the CMake configuration script of FindMPI.cmake where the conditional check for compiler IDs seems to incorrectly handle or parse the compiler ID, leading to unexpected behavior or a configuration error see https:...Encountered an issue in the CMake configuration script of FindMPI.cmake where the conditional check for compiler IDs seems to incorrectly handle or parse the compiler ID, leading to unexpected behavior or a configuration error see https://gitlab.kitware.com/cmake/cmake/-/blob/v3.29.0/Modules/FindMPI.cmake#L351-352
**Suggested Fix**:
```
foreach (id IN ITEMS Fujitsu FujitsuClang GNU Intel IntelLLVM MSVC PGI XL)
if (NOT CMAKE_${LANG}_COMPILER_ID OR CMAKE_${LANG}_COMPILER_ID STREQUAL ${id})
```https://gitlab.kitware.com/cmake/cmake/-/issues/25819cxx_std_26 not available with Clang 192024-03-25T15:17:08-04:00H-G-Hristovcxx_std_26 not available with Clang 19I'd like to do this on a global scale:
```cmake
add_library(MyBaseLibrary INTERFACE)
target_compile_features(MyBaseLibrary
INTERFACE
cxx_std_26
)
```
But I get an error:
```
[cmake] CMake Error in app/CMakeLists.txt:
[cmake] ...I'd like to do this on a global scale:
```cmake
add_library(MyBaseLibrary INTERFACE)
target_compile_features(MyBaseLibrary
INTERFACE
cxx_std_26
)
```
But I get an error:
```
[cmake] CMake Error in app/CMakeLists.txt:
[cmake] The compiler feature "cxx_std_26" is not known to CXX compiler
[cmake]
[cmake] "Clang"
[cmake]
[cmake] version 19.0.0.
```
Is this expected and I misunderstand how to use target compile features?3.29.1Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/25817cmake-gui doesn't consider a configure preset "valid" unless a generator is s...2024-03-25T13:56:38-04:00Richard Thomsoncmake-gui doesn't consider a configure preset "valid" unless a generator is specifiedThe documentation specifically states that the `generator` field may be omitted:
> In version 3 or above, this field may be omitted to fall back to regular generator discovery procedure.
This minimal configure preset doesn't show as 'v...The documentation specifically states that the `generator` field may be omitted:
> In version 3 or above, this field may be omitted to fall back to regular generator discovery procedure.
This minimal configure preset doesn't show as 'valid' in cmake-gui and is disabled.
```
{
"version": 5,
"cmakeMinimumRequired": {
"major": 3,
"minor": 23,
"patch": 0
},
"configurePresets": [
{
"name": "default",
"displayName": "Configure with default settings"
}
]
}
```
If I add a `generator` field, then cmake-gui considers it valid:
```
{
"version": 5,
"cmakeMinimumRequired": {
"major": 3,
"minor": 23,
"patch": 0
},
"configurePresets": [
{
"name": "default",
"displayName": "Configure with default settings",
"generator": "Visual Studio 17 2022"
}
]
}
```
Diagnostics about 'malformed' presets are an area where both the command-line tool and the GUI tool need improvement. The GUI is completely silent about whatever it considers to be the problem and the command-line tool often just says 'invalid' without giving any information about the context of the encountered error.https://gitlab.kitware.com/cmake/cmake/-/issues/25816find_package: Search within frameworks and xcframeworks2024-03-25T13:54:54-04:00Maartenfind_package: Search within frameworks and xcframeworksHow can I embed CMake configuration files in xcframework's?
The [currently supported search procedures](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure) only contain regular directory structures...How can I embed CMake configuration files in xcframework's?
The [currently supported search procedures](https://cmake.org/cmake/help/latest/command/find_package.html#config-mode-search-procedure) only contain regular directory structures, macos apps and frameworks.
It would be useful to embed configuration files so to be able to use `find_package` for xcframework's as well.
Internally, xcframeworks are a collection of frameworks.
For reference, this is the tree of a SDL3 xcframework (limited to depth 3):
```
SDL3.xcframework/
├── Info.plist
├── ios-arm64
│ └── SDL3.framework
│ ├── default.metallib
│ ├── Headers
│ ├── Info.plist
│ ├── License.txt
│ ├── ReadMe.txt
│ └── SDL3
├── ios-arm64_x86_64-simulator
│ └── SDL3.framework
│ ├── _CodeSignature
│ ├── default.metallib
│ ├── Headers
│ ├── Info.plist
│ ├── License.txt
│ ├── ReadMe.txt
│ └── SDL3
├── macos-arm64_x86_64
│ └── SDL3.framework
│ ├── Headers -> Versions/Current/Headers
│ ├── Resources -> Versions/Current/Resources
│ ├── SDL3 -> Versions/Current/SDL3
│ └── Versions
├── tvos-arm64
│ └── SDL3.framework
│ ├── default.metallib
│ ├── Headers
│ ├── Info.plist
│ ├── License.txt
│ ├── ReadMe.txt
│ └── SDL3
└── tvos-arm64_x86_64-simulator
└── SDL3.framework
├── _CodeSignature
├── default.metallib
├── Headers
├── Info.plist
├── License.txt
├── ReadMe.txt
└── SDL3
```
I believe CMake should, when e.g. targeting macos on arm64, look into the following additional directories when doing `find_package(SDL3)`:
- `SDL3.xcframework/macos-arm64_x86_64/SDL3.framework/Resources` (depends on the current target)
- `SDL3.xcframework/Resources`https://gitlab.kitware.com/cmake/cmake/-/issues/25813export(TARGETS) for add_library() defined in another file doesn't generate ta...2024-03-25T13:46:52-04:00Rafał Świdzińskiexport(TARGETS) for add_library() defined in another file doesn't generate target-<target>-<config>.cmake for CXX_MODULEs\[3.28.0\]
If `export()` command isn't in the same file scope as the `add_library()`, the file `${CMAKE_BINARY_DIR}/cmake/modules/target-calc-Debug.cmake` won't get created causing an issue in consuming project.
My top level listfile:
...\[3.28.0\]
If `export()` command isn't in the same file scope as the `add_library()`, the file `${CMAKE_BINARY_DIR}/cmake/modules/target-calc-Debug.cmake` won't get created causing an issue in consuming project.
My top level listfile:
```
cmake_minimum_required(VERSION 3.28)
project(ExportCalc CXX)
add_subdirectory(src bin)
export(TARGETS calc
FILE "${CMAKE_BINARY_DIR}/cmake/CalcTargets.cmake"
CXX_MODULES_DIRECTORY "modules"
NAMESPACE Calc::
)
```
And a listfile in src:
```
add_library(calc STATIC basic.cpp)
target_sources(calc
PUBLIC FILE_SET CXX_MODULES FILES extended.cppm
)
target_compile_features(calc PRIVATE cxx_std_20)
set_target_properties(calc PROPERTIES CXX_EXTENSIONS OFF)
```Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25811Feature request: Treat configuration warnings as errors2024-03-22T12:16:10-04:00Dan RavivFeature request: Treat configuration warnings as errorsIt would be helpful to be able to make CMake treat configuration warnings as errors.
Previously requested here https://discourse.cmake.org/t/cmake-warnings-as-error/3960It would be helpful to be able to make CMake treat configuration warnings as errors.
Previously requested here https://discourse.cmake.org/t/cmake-warnings-as-error/3960https://gitlab.kitware.com/cmake/cmake/-/issues/25806VS: Behaviour of CXX_SCAN_FOR_MODULES in Visual Studio generated projects2024-03-25T10:00:55-04:00David HunterVS: Behaviour of CXX_SCAN_FOR_MODULES in Visual Studio generated projectsThis is not so much a bug as issue with how CMake generates the MSBuild XML for a Visual Studio project file.
This is using CMake 3.29.
So I create a simple Hello World executable, set the C++ version to C++23 and generate a Visual Stu...This is not so much a bug as issue with how CMake generates the MSBuild XML for a Visual Studio project file.
This is using CMake 3.29.
So I create a simple Hello World executable, set the C++ version to C++23 and generate a Visual Studio solution.
Everything works fine.
I now want to use `import std;` so I add
`set_target_properties(hello_world PROPERTIES CXX_SCAN_FOR_MODULES true)`
This works and I can `import std;`. However when I look in the build properties in the Visual Studio GUI for the project. I see
`Scan Sources for Module Dependencies : No`
I was very confused by this.
So I looked in the vcxproj file and I see the MSBuild setting
`<ScanSourceForModuleDependencies>false</ScanSourceForModuleDependencies>` note the "false" here.
After more confusion I then discovered that there were source file specific settings like
`ScanSourceForModuleDependencies Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">true</ScanSourceForModuleDependencies>`
So at the moment CMake seems to always set the project wide setting to false and then always overrides is on the sources.
So things work because the source file settings were overriding the project settings.
This seems wrong to me the behavior I expect would be
- Setting the property `CXX_SCAN_FOR_MODULES` on a target should control the MSBuild setting for the project
- Setting the property `CXX_SCAN_FOR_MODULES` on a source should control the MSBuild setting on a source file
That way the `<ScanSourceForModuleDependencies>` only appears in the output on a source if it has explicitly been set but the CMakeLists.txt.
In an ideal world you would only add `<ScanSourceForModuleDependencies>` to a source file if the value differs from the project setting
but that would just be an optimization.
### `BuildStlModules`
On a related topic MSBuild does have a `BuildStlModules` setting. This seems to be a subset of `ScanSourceForModuleDependencies` and it allows you to use `import std;` but does not switch on full module support. I'm not sure if this a build time optimization thing. Maybe this is worth supporting if the other compilers are going to do something similar.Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25804Reproducible Builds: Passing --date to jar in2024-03-21T16:12:04-04:00kpcyrdReproducible Builds: Passing --date to jar inHello!
I'm trying to reproduce a .jar that was built with CMake, the jar content seems to match but the .jar itself contains timestamps of the buildtime.
```
│ ├── usr/share/java/turbojpeg.jar
│ │ ├── zipinfo {}
│ │ │ @@ -1,18 +1,18 @@...Hello!
I'm trying to reproduce a .jar that was built with CMake, the jar content seems to match but the .jar itself contains timestamps of the buildtime.
```
│ ├── usr/share/java/turbojpeg.jar
│ │ ├── zipinfo {}
│ │ │ @@ -1,18 +1,18 @@
│ │ │ Zip file size: 56496 bytes, number of entries: 16
│ │ │ --rw---- 1.0 fat 0 bx stor 24-Jan-25 22:04 META-INF/
│ │ │ --rw---- 2.0 fat 74 bl defN 24-Jan-25 22:04 META-INF/MANIFEST.MF
│ │ │ --rw---- 2.0 fat 736 bl defN 24-Jan-25 22:04 TJBench$DummyDCTFilter.class
│ │ │ --rw---- 2.0 fat 37319 bl defN 24-Jan-25 22:04 TJBench.class
│ │ │ --rw---- 2.0 fat 11777 bl defN 24-Jan-25 22:04 TJExample.class
│ │ │ --rw---- 2.0 fat 24985 bl defN 24-Jan-25 22:04 TJUnitTest.class
│ │ │ --rw---- 2.0 fat 4555 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJ.class
│ │ │ --rw---- 2.0 fat 8937 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJCompressor.class
│ │ │ --rw---- 2.0 fat 336 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJCustomFilter.class
│ │ │ --rw---- 2.0 fat 12512 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJDecompressor.class
│ │ │ --rw---- 2.0 fat 904 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJException.class
│ │ │ --rw---- 2.0 fat 1124 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJLoader.class
│ │ │ --rw---- 2.0 fat 925 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJScalingFactor.class
│ │ │ --rw---- 2.0 fat 1429 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJTransform.class
│ │ │ --rw---- 2.0 fat 2469 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/TJTransformer.class
│ │ │ --rw---- 2.0 fat 4552 bl defN 24-Jan-25 22:04 org/libjpegturbo/turbojpeg/YUVImage.class
│ │ │ +-rw---- 1.0 fat 0 bx stor 24-Mar-02 04:40 META-INF/
│ │ │ +-rw---- 2.0 fat 74 bl defN 24-Mar-02 04:40 META-INF/MANIFEST.MF
│ │ │ +-rw---- 2.0 fat 736 bl defN 24-Mar-02 04:40 TJBench$DummyDCTFilter.class
│ │ │ +-rw---- 2.0 fat 37319 bl defN 24-Mar-02 04:40 TJBench.class
│ │ │ +-rw---- 2.0 fat 11777 bl defN 24-Mar-02 04:40 TJExample.class
│ │ │ +-rw---- 2.0 fat 24985 bl defN 24-Mar-02 04:40 TJUnitTest.class
│ │ │ +-rw---- 2.0 fat 4555 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJ.class
│ │ │ +-rw---- 2.0 fat 8937 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJCompressor.class
│ │ │ +-rw---- 2.0 fat 336 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJCustomFilter.class
│ │ │ +-rw---- 2.0 fat 12512 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJDecompressor.class
│ │ │ +-rw---- 2.0 fat 904 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJException.class
│ │ │ +-rw---- 2.0 fat 1124 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJLoader.class
│ │ │ +-rw---- 2.0 fat 925 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJScalingFactor.class
│ │ │ +-rw---- 2.0 fat 1429 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJTransform.class
│ │ │ +-rw---- 2.0 fat 2469 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/TJTransformer.class
│ │ │ +-rw---- 2.0 fat 4552 bl defN 24-Mar-02 04:40 org/libjpegturbo/turbojpeg/YUVImage.class
│ │ │ 16 files, 112634 bytes uncompressed, 53932 bytes compressed: 52.1%
```
The `jar` executable has a `--date` option to normalize this, but there's currently no way to configure this in CMake (although I'd love to be corrected on this). Ideally the `--date` flag would be set automatically if the `SOURCE_DATE_EPOCH` environment variable is set to a value. This environment variable is already referenced at other places in the CMake codebase.
Thanks!