CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-02-09T09:17:21-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25573ci: Incomplete testing for CMake's Swift support on Windows2024-02-09T09:17:21-05:00Brad Kingci: Incomplete testing for CMake's Swift support on WindowsCMake's CI pipelines ~~do not cover~~ do not fully cover Swift on Windows.CMake's CI pipelines ~~do not cover~~ do not fully cover Swift on Windows.https://gitlab.kitware.com/cmake/cmake/-/issues/25572Swift/Ninja: Use a response file for swift sources2024-01-12T08:53:17-05:00Saleem AbdulrasoolSwift/Ninja: Use a response file for swift sourcesWe currently use a response file for Swift which only includes the flags to match the behaviour with other languages. However, Swift does module at a time compilation, passing all the sources to the invocation. This can quickly exceed th...We currently use a response file for Swift which only includes the flags to match the behaviour with other languages. However, Swift does module at a time compilation, passing all the sources to the invocation. This can quickly exceed the command line limit on Windows which will break the invocation. We should isolate the file list and pass it via a secondary response file.https://gitlab.kitware.com/cmake/cmake/-/issues/25571Duplicate libraries when linking against both aliased and non-aliased version...2024-01-08T09:23:21-05:00Joel McKenzieDuplicate libraries when linking against both aliased and non-aliased versions of a libraryIf a library/executable links (transitively or not) against both an alias library and the original non-aliased library, the libraries are duplicated on the linker command line, which causes warnings on the apple linker (potentially other...If a library/executable links (transitively or not) against both an alias library and the original non-aliased library, the libraries are duplicated on the linker command line, which causes warnings on the apple linker (potentially others, I didn't check). In an ideal world only the alias-ed library would be linked against in CMake, but library developers don't always follow these rules, in the case I'm dealing with the library developer links directly against the non-aliased name for the library internally but exposes an aliased version that others are expected to link against.
This could be handled gracefully by deduplicating aliased and non-aliased versions of the same library when constructing linker commands.
I put together a minimal project showing the issue here:
https://github.com/jmcken8/cmake-duplicate-lib-bug
Tested on:
- cmake 3.27.7
- cmake 3.28.1https://gitlab.kitware.com/cmake/cmake/-/issues/25570FindOpenMP: Optionally use /openmp:{experimental,llvm} with MSVC2024-03-27T13:52:29-04:00adal devFindOpenMP: Optionally use /openmp:{experimental,llvm} with MSVCwith msvc compiler, ```findpackage(OpenMP)``` gives ```OpenMP_CXX_FLAGS -openmp```
Expected flag would be ```/openmp```.
Even better it should be possible to select between ```/openmp```, ```/openmp:experimental``` or ```/openmp:llvm``...with msvc compiler, ```findpackage(OpenMP)``` gives ```OpenMP_CXX_FLAGS -openmp```
Expected flag would be ```/openmp```.
Even better it should be possible to select between ```/openmp```, ```/openmp:experimental``` or ```/openmp:llvm``` (in order to access more recent OpenMP).https://gitlab.kitware.com/cmake/cmake/-/issues/25567FindCUDAToolkit: Prefer location of CMAKE_CUDA_COMPILER even when CUDA langua...2024-02-13T14:21:51-05:00Eyal Rozenbergeyalroz1@gmx.comFindCUDAToolkit: Prefer location of CMAKE_CUDA_COMPILER even when CUDA language not enabledI have several CUDA versions installed under `/usr/local`, one of which is linked to by `/usr/local/cuda` as is customary. Occasionally I force the use of one of them by specifying `-DCMAKE_CUDA_COMPILER` in the invocation of CMake; and ...I have several CUDA versions installed under `/usr/local`, one of which is linked to by `/usr/local/cuda` as is customary. Occasionally I force the use of one of them by specifying `-DCMAKE_CUDA_COMPILER` in the invocation of CMake; and this works. However - if I perform `find_package(CUDAToolkit)`, before actually enabling the CUDA language (e.g. in some test programs) - I get `/usr/local/cuda` as the found toolkit location, even though that's a different version than the CUDA compiler I've chosen.
Now, there's the question of whether it is at all legitimate to use a CUDA compiler of version X and find the CUDA toolkit at version Y != X ; but putting that aside: the FindCUDAToolkit module should prefer a toolkit version corresponding to the specified compiler's, and at the very least start its search around the compiler's location, i.e. if I use `/usr/local/cuda-9.0/bin/nvcc`, it should definitely try `/usr/local/cuda-9.0` before trying `/usr/local/cuda`. That's how it works after enabling the language, but it should also work the same before enabling it.https://gitlab.kitware.com/cmake/cmake/-/issues/25565CUDA+VisualStudio compilation fails with: A single input file is required for...2024-02-09T09:38:15-05:00Johannes SchönbergerCUDA+VisualStudio compilation fails with: A single input file is required for a non-link phase when an outputfile is specifiedCompiling the colmap library with latest CMake 3.28.1 and latest CUDA 12.3.2 fails both with the VS and Ninja generators.
There are two main issues:
1. The `/EHsc` flag is directly passed to nvcc but should only be included in the `-Xc...Compiling the colmap library with latest CMake 3.28.1 and latest CUDA 12.3.2 fails both with the VS and Ninja generators.
There are two main issues:
1. The `/EHsc` flag is directly passed to nvcc but should only be included in the `-Xcompiler` argument (applies to both VS/Ninja)
2. The pdb file path passed through `-Xcompiler` is not quoted (applies to Ninja)
Replicate the issue (note that vcpkg defaults to CMake 3.27.X but the same issue happens under 3.28.1):
```
git clone https://github.com/Microsoft/vcpkg.git
cd vcpkg
.\bootstrap-vcpkg.bat
.\vcpkg.exe install colmap[cuda-redist]:x64-windows`
...
```
The error logs then show the following:
```
FAILED: src/colmap/mvs/CMakeFiles/colmap_mvs_cuda.dir/gpu_mat_prng.cu.obj
C:\PROGRA~1\NVIDIA~2\CUDA\v12.3\bin\nvcc.exe -forward-unknown-to-host-compiler -DCOLMAP_CGAL_ENABLED -DCOLMAP_CUDA_ENABLED -DCOLMAP_GPU_ENABLED -DCOLMAP_GUI_ENABLED -DCOLMAP_OPENGL_ENABLED -DCOLMAP_OPENMP_ENABLED -DGFLAGS_IS_A_DLL=1 -DGLOG_NO_ABBREVIATED_SEVERITIES -DGL_GLEXT_PROTOTYPES -DIMATH_DLL -DNOMINMAX -DOPENEXR_DLL -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DWIN32_LEAN_AND_MEAN -D_MWAITXINTRIN_H_INCLUDED -IC:\dev\colmap\src -isystem C:\dev\vcpkg\installed\x64-windows-release\include -isystem C:\dev\vcpkg\installed\x64-windows-release\include\eigen3 -isystem C:\dev\vcpkg\installed\x64-windows-release\include\qt5 -isystem C:\dev\vcpkg\installed\x64-windows-release\include\qt5\QtCore -isystem C:\dev\vcpkg\installed\x64-windows-release\tools\qt5\mkspecs\win32-msvc -isystem C:\dev\vcpkg\installed\x64-windows-release\include\qt5\QtOpenGL -isystem C:\dev\vcpkg\installed\x64-windows-release\include\qt5\QtWidgets -isystem C:\dev\vcpkg\installed\x64-windows-release\include\qt5\QtGui -isystem C:\dev\vcpkg\installed\x64-windows-release\include\webp -isystem C:\dev\vcpkg\installed\x64-windows-release\include\OpenEXR -isystem C:\dev\vcpkg\installed\x64-windows-release\include\Imath -isystem "C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v12.3\include" -D_WINDOWS -Xcompiler="/W3 /GR /EHsc" -Xcompiler="-MD -O2 -Ob2" -DNDEBUG -std=c++14 "--generate-code=arch=compute_70,code=[compute_70,sm_70]" /EHsc -MD -MT src\colmap\mvs\CMakeFiles\colmap_mvs_cuda.dir\gpu_mat_prng.cu.obj -MF src\colmap\mvs\CMakeFiles\colmap_mvs_cuda.dir\gpu_mat_prng.cu.obj.d -x cu -c C:\dev\colmap\src\colmap\mvs\gpu_mat_prng.cu -o src\colmap\mvs\CMakeFiles\colmap_mvs_cuda.dir\gpu_mat_prng.cu.obj -Xcompiler=-Fdsrc\colmap\mvs\CMakeFiles\colmap_mvs_cuda.dir\colmap_mvs_cuda.pdb,-FS
nvcc fatal : A single input file is required for a non-link phase when an outputfile is specified
```
Executing the above command manually by quoting `-Xcompiler="-Fdsrc\colmap\mvs\CMakeFiles\colmap_mvs_cuda.dir\colmap_mvs_cuda.pdb,-FS"` and removing the `/EHsc` flag (keeping the ones passed through `-Xcompiler`) fixes the issue.https://gitlab.kitware.com/cmake/cmake/-/issues/25564Threads should either trigger language enablement, or not rely on it2024-01-06T16:47:17-05:00Eyal Rozenbergeyalroz1@gmx.comThreads should either trigger language enablement, or not rely on itConsider the following CMakeLists:
```
make_minimum_required(VERSION 3.25 FATAL_ERROR)
project(foo Fortran)
find_package(Threads)
add_library(foo INTERFACE foo.f90)
if (Threads_FOUND)
target_link_libraries(foo INTERFACE Threads::Thre...Consider the following CMakeLists:
```
make_minimum_required(VERSION 3.25 FATAL_ERROR)
project(foo Fortran)
find_package(Threads)
add_library(foo INTERFACE foo.f90)
if (Threads_FOUND)
target_link_libraries(foo INTERFACE Threads::Threads)
endif()
```
this fails at `find_package()`, with the error:
```
CMake Error at /path/to/cmake/Modules/FindThreads.cmake:66 (message):
FindThreads only works if either C or CXX language is enabled
Call Stack (most recent call first):
CMakeLists.txt:4 (find_package)
```
This failure doesn't make sense. If a package can require the enablement of a language - then it should be able to _trigger_ the enablement of that language, itself. And on the contrary, if a package can't require the enablement of the language, then it is illegitimate for FindThreads to fail this way.https://gitlab.kitware.com/cmake/cmake/-/issues/25562cmake 3.28.x hanging on configure with arm64/rosetta2024-01-25T11:00:03-05:00Matias Lopezcmake 3.28.x hanging on configure with arm64/rosettaWe have been getting reports of devs on macOS builds hanging through docker. We have reproduce with both versions 3.28.x but not 3.27.6. We have reproduced with rhel 7, 8, and ubuntu. The only commonality is 3.28.x, macOS, docker with bu...We have been getting reports of devs on macOS builds hanging through docker. We have reproduce with both versions 3.28.x but not 3.27.6. We have reproduced with rhel 7, 8, and ubuntu. The only commonality is 3.28.x, macOS, docker with buildkit, and rosetta (because the images were for amd64).
<details>
<summary>files</summary>
```cml
cmake_minimum_required(VERSION 3.20)
project(Test)
```
```Dockerfile
FROM <IMAGE>
RUN yum install -y make.x86_64
COPY cmake-3.28.1-linux-x86_64.tar.gz /
RUN tar -xf /cmake-3.28.1-linux-x86_64.tar.gz
RUN mkdir /src/
COPY CMakeLists.txt /src/
COPY test.sh /src/
RUN chmod +x /src/test.sh
ENV PATH="${PATH}:/cmake-3.28.1-linux-x86_64/bin"
WORKDIR /src/
ENTRYPOINT [ "/src/test.sh" ]
```
```sh
#!/bin/sh
for i in `seq 1 10` ; do
mkdir build$i
cd build$i
cmake .. &
cd ..
done
wait
```
</details>
We suspect that it relates to https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8665 from a trace we got while hung:
```
(gdb) where
#0 0x00007ffffecbd0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x0000000000e1b13d in uv.io_poll ()
#2 0x0000000000e0c066 in uv_run ()
#3 0x00000000006ab72e in cmExecuteProcessCommand(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, cmExecutionStatus&) ()
#4 0x00000000005dcc4f in std::_Function_handler<bool (std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&), cmState::AddBuiltinCommand(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool (*)(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, cmExecutionStatus&))::lambda(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&)#1 <GO>>::_M_invoke(std::_Any_data const&, std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) ()
#5 0x00000000005893a7 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&, std::optional<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >) ()
```https://gitlab.kitware.com/cmake/cmake/-/issues/25558maintenance of moderncmakedomain2024-01-05T17:13:33-05:00Cristian Lemaintenance of moderncmakedomainRight now `moderncmakedomain` is a clone of the implementation in cmake upstream. But this makes it hard to further develop it for the external users, and it is unclear what the plans are for this. Primarily the issues are in #25553.
Im...Right now `moderncmakedomain` is a clone of the implementation in cmake upstream. But this makes it hard to further develop it for the external users, and it is unclear what the plans are for this. Primarily the issues are in #25553.
Imo the best approach is to move the whole sphinx extension and its development to `moderncmakedomain` and have upstream import it.
Cc: @henryiiihttps://gitlab.kitware.com/cmake/cmake/-/issues/25557Documentation: Missing mention of the [variant=<Config>] syntax for [CMAKE_]_...2024-01-08T10:44:48-05:00Ilya KulakovDocumentation: Missing mention of the [variant=<Config>] syntax for [CMAKE_]_XCODE_ATTRIBUTE_<attribute> variables and properties.CMake allows to specify Xcode Configuration that a given Xcode attribute applies to, regardless whether set via a variable or property:
```cmake
set_target_properties(...
XCODE_ATTRIBUTE_LLVM_LTO "Monolithic"
XCODE_ATTRIBUTE_LLV...CMake allows to specify Xcode Configuration that a given Xcode attribute applies to, regardless whether set via a variable or property:
```cmake
set_target_properties(...
XCODE_ATTRIBUTE_LLVM_LTO "Monolithic"
XCODE_ATTRIBUTE_LLVM_LTO[variant=Debug] "Incremental"
)
```
will set the `LLVM_LTO` build setting to `Monolithic` for all Xcode configurations but Debug which will be set to `Incremental` instead.
Neither [`CMAKE_XCODE_ATTRIBUTE_<an-attribute>`](https://cmake.org/cmake/help/latest/variable/CMAKE_XCODE_ATTRIBUTE_an-attribute.html) nor [`XCODE_ATTRIBUTE_<an-attribute>`](https://cmake.org/cmake/help/latest/prop_tgt/XCODE_ATTRIBUTE_an-attribute.html) mentions that.
https://cmake.org/Bug/view.php?id=8179https://gitlab.kitware.com/cmake/cmake/-/issues/25556presets: Preset activation status inheritance2024-01-23T01:18:01-05:00Martin Blanchardpresets: Preset activation status inheritanceTrying to minimise the combinatorial explosion described at #22538, I was thinking of using multi-inheritance on conditional presets, hoping that the parent downstream preset would only inherit fields from non-disabled upstream presets. ...Trying to minimise the combinatorial explosion described at #22538, I was thinking of using multi-inheritance on conditional presets, hoping that the parent downstream preset would only inherit fields from non-disabled upstream presets.
Given the following `CMakePresets.json` snippet:
```json
"configurePresets": [
{
"hidden": true,
"name": "linux-build",
"toolchainFile": "linux-toolchain.cmake",
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Linux"
}
},
{
"hidden": true,
"name": "windows-build",
"toolchainFile": "windows-toolchain.cmake",
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Windows"
}
},
{
"name": "release-build",
"displayName": "Release Build",
"inherits": [
"linux-build",
"windows-build",
"first-option",
"second-option"
]
}
```
With CMake 3.26.3, it seems like `release-build` activation status always evaluates to its first inherited status, here `linux-build` activation status. I'm not sure if that behavior is documented at [`cmake-presets`](https://cmake.org/cmake/help/latest/manual/cmake-presets.7.html). I guess the following somehow gives it credence:
> If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits array will be preferred.
But I think it would be a lot more useful to have the activation status a given downstream preset be computed from the status of all its upsteam ones (deactivating it only if all its upstream presets are themself deactivated). Meaning here that:
``status("release-build") = status("linux-build") OR status("windows-build") OR status("first-option") OR status("second-option")``
And of course `release-build` would only inherit fields from active presets!https://gitlab.kitware.com/cmake/cmake/-/issues/25555Module libraries: Option to add dynamic lookup flag for Darwin modules2024-01-12T10:56:04-05:00Ilya AndreevModule libraries: Option to add dynamic lookup flag for Darwin modulesModules are used for dynamic plugins, which may have undefined references if they use the APIs of other libraries.
On Linux, it is enough to mark these other libraries as `OBJECT` and the plugin as `MODULE` and it will just work. On Dar...Modules are used for dynamic plugins, which may have undefined references if they use the APIs of other libraries.
On Linux, it is enough to mark these other libraries as `OBJECT` and the plugin as `MODULE` and it will just work. On Darwin on top of that we need to add a linker specific flag `-undefined dynamic_lookup`.
I think this should be enabled for darwin `MODULES` by default to exclude platform specific code from plugins cmake lists.
A small example of the issue is here (README and Github Actions included): https://github.com/bugdea1er/dynamic_lookup. It defines an OBJECT and a MODULE library. The main problem here, as I see it, is that the behaviour is different on these platforms and CMake does not provide a cross-platform method for adding the flag where needed.https://gitlab.kitware.com/cmake/cmake/-/issues/25553sphinx: autodoc support2024-01-05T17:12:35-05:00Cristian Lesphinx: autodoc supportCurrently the roles and directives in the sphinx module do not follow the standard form of like the `python` domain or the [`matlab`](https://github.com/sphinx-contrib/matlabdomain). This creates problems for downstream users of moderncm...Currently the roles and directives in the sphinx module do not follow the standard form of like the `python` domain or the [`matlab`](https://github.com/sphinx-contrib/matlabdomain). This creates problems for downstream users of moderncmakedomain, particularly when they mix it with myst-parser. E.g. having nested documentation of module and function breaks down because they are mixed.
Some restructuring that can help:
- convert the python module into a python package, separating `domain`, `directive`, `auto-api`/`documenter`, etc.
- follow the domain/auto-api syntax, i.e. `cmake:module` is the domain role, `cmake:auto-module` the crawler that populates it
- include an `indexer` and resolve-any-xref
- remove duplicate `command:`, etc. tags from intersphinx linkage
- overall replicate the python/matlab domain as much as possiblehttps://gitlab.kitware.com/cmake/cmake/-/issues/25550Fail better if enable_language() invoked before a project is defined2024-01-29T10:55:04-05:00Eyal Rozenbergeyalroz1@gmx.comFail better if enable_language() invoked before a project is definedIf we configure using the following `CMakeLists.txt`:
```
cmake_minimum_required(VERSION 3.25)
enable_language(CUDA)
# Note: if we move the projct command here, all is fine
include(FindCUDA/select_compute_arch)
CUDA_DETECT_INSTALLED_GPUS...If we configure using the following `CMakeLists.txt`:
```
cmake_minimum_required(VERSION 3.25)
enable_language(CUDA)
# Note: if we move the projct command here, all is fine
include(FindCUDA/select_compute_arch)
CUDA_DETECT_INSTALLED_GPUS(INSTALLED_GPU_CCS_1)
project(foo CUDA)
```
We get:
```
CMake Error at /path/to/cmake/3.28.1/share/cmake-3.28/Modules/FindCUDA/select_compute_arch.cmake:120 (file):
file failed to open for writing (Permission denied):
/detect_cuda_compute_capabilities.cu
Call Stack (most recent call first):
CMakeLists.txt:5 (CUDA_DETECT_INSTALLED_GPUS)
```
and some additional errors. Now, the problematic file is defined as:
```
"${PROJECT_BINARY_DIR}/detect_cuda_compute_capabilities.cu
```
which sort-of assumes ${PROJECT_BINARY_DIR} is not empty. Yet - it is empty before a project has been defined. **edit:** Since, apparently, enabling languages before a project is defined is unsupported, then the `enable_language(CUDA)` command should be failing immediately, with the error saying that it can't be invoked with no project defined; the half-hearted effort doomed to fail is confusing to users.https://gitlab.kitware.com/cmake/cmake/-/issues/25549CMake's cmake-cxxmodules(7) requires new high-level tutorial2024-01-08T10:46:13-05:00AlexCMake's cmake-cxxmodules(7) requires new high-level tutorialThe current manual, [`cmake-cxxmodules(7)`](https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html) is catastrophically lacking information about how to use it.
I suggest to add new tutorial and reuse the `MathFunctions` fro...The current manual, [`cmake-cxxmodules(7)`](https://cmake.org/cmake/help/latest/manual/cmake-cxxmodules.7.html) is catastrophically lacking information about how to use it.
I suggest to add new tutorial and reuse the `MathFunctions` from Tutorials as imported modules.
Thanks and Happy New Year!https://gitlab.kitware.com/cmake/cmake/-/issues/25547find_library: --debug-find output doesn't include considered framework locations2024-01-08T10:47:40-05:00Ilya Kulakovfind_library: --debug-find output doesn't include considered framework locationsCMake's `cmFindLibraryCommand::FindFrameworkLibraryDirsPerName` and `cmFindLibraryCommand::FindFrameworkLibraryNamesPerDir` don't use `DebugLibraryFailed` and `DebugLibraryFound`. Thus these attempts stay hidden from the user trying to d...CMake's `cmFindLibraryCommand::FindFrameworkLibraryDirsPerName` and `cmFindLibraryCommand::FindFrameworkLibraryNamesPerDir` don't use `DebugLibraryFailed` and `DebugLibraryFound`. Thus these attempts stay hidden from the user trying to debug find.https://gitlab.kitware.com/cmake/cmake/-/issues/25540Want ability to make find_package more verbose2024-01-09T20:46:09-05:00Eyal Rozenbergeyalroz1@gmx.comWant ability to make find_package more verboseWith some find-scripts, when the package is found, we get a message mentioning the version, and possibly other information:
```
-- Found CUDAToolkit: /usr/local/cuda/targets/x86_64-linux/include (found suitable version "11.2.67", minimum...With some find-scripts, when the package is found, we get a message mentioning the version, and possibly other information:
```
-- Found CUDAToolkit: /usr/local/cuda/targets/x86_64-linux/include (found suitable version "11.2.67", minimum required is "9.0")
```
However, in `CONFIG` mode - `find_package()` itself will not issue such a message, AFAICT, ever. There is no parameter/modified one can pass on to `find_package` for ensuring this notice is printed. IMHO, there should be! We have QUIET, to ensure nothing is said; Why not the opposite?
The simplest would be a `VERBOSE` which mentions the version found and the minimum required version, or required range, if one was specified. One could be more fancy and also print some location info, but perhaps better not to go there. So, for:
```
find_package(foo 11.2 11.0..<11.3)
```
we would get something like:
```
-- Found Foo (version "11.2.67", minimum required is "11.0")
```https://gitlab.kitware.com/cmake/cmake/-/issues/25539cxxmodules: use synthetic targets to provide modules within a project as well2024-02-14T23:21:58-05:00melak47cxxmodules: use synthetic targets to provide modules within a project as wellWhen using C++20 modules in shared libraries on MSVC (using the Ninja generator), `__declspec(dllexport)` declarations
end up getting exported from module interfaces. These declarations then get imported by consumers of the module.
Th...When using C++20 modules in shared libraries on MSVC (using the Ninja generator), `__declspec(dllexport)` declarations
end up getting exported from module interfaces. These declarations then get imported by consumers of the module.
This works, but is not ideal, as it incurs an extra indirection for calls to functions from the library.
(See <https://stackoverflow.com/a/74444920> for a more detailed look at this).
Ideally we would have:
- the code compiled into the library sees `__declspec(dllexport)` declarations
- the code using the library sees `__declspec(dllimport)` declarations
With headers, we have `generate_export_header` to achieve this. To get the same approach working with modules,
the module interfaces of the library would need to be compiled a second time for its consumers.
After reading about `CXX_MODULES` file-sets on `IMPORTED` targets, it sounds like the synthesized target might do just that:
```cmake
add_library(mod SHARED src/mod.cpp)
target_sources(mod PRIVATE FILE_SET CXX_MODULES FILES src/mod.ixx)
target_compile_features(mod PUBLIC cxx_std_20)
target_compile_definitions(mod PUBLIC MOD_SHARED PRIVATE MOD_EXPORTS)
add_library(mod_import INTERFACE IMPORTED)
target_sources(mod_import INTERFACE FILE_SET CXX_MODULES FILES src/mod.ixx)
target_link_libraries(mod_import INTERFACE mod)
set_target_properties(mod_import PROPERTIES CXX_STANDARD 20 CXX_STANDARD_REQUIRED ON)
```
But for some reason, the synthesized target only contains the module map & dyndep steps,
no .ifc file is actually generated (and `.bmi` files are referenced in the modmap file instead of `.ifc`).
The consuming target's modmap then ends up as:
```
-reference mod=
```
Which doesn't work.
The workaround I found was adding the module interface to the consuming target manually:
```cmake
add_executable(main src/main.cpp)
target_sources(main PRIVATE FILE_SET CXX_MODULES FILES src/mod.ixx)
target_link_libraries(main PRIVATE mod)
```
which succeeds and uses the "dllimport" version of the interface (despite some errors :eyes:):
```
CMake Error: Disagreement of the location of the 'mod' module. Location A: 'CMakeFiles\mod.dir\mod.ifc' via by-name; Location B: 'CMakeFiles\main.dir\mod.ifc' via by-name.
CMake Error: Disagreement of the location of the 'mod' module. Location A: 'CMakeFiles\mod.dir\mod.ifc' via by-name; Location B: 'CMakeFiles\main.dir\mod.ifc' via by-name.
```
Neither of these two approaches really seems like the "intended" way to go, though.
Versions used: CMake 3.28.1, ninja 1.11.1, msvc 19.38
[mod.ixx](/uploads/d2b287b34e9a3d12dfaa5fbec17c460c/mod.ixx)
[mod.cpp](/uploads/fea659c95571a22a27cdaf84d766dfb9/mod.cpp)
[main.cpp](/uploads/eed517e2d3bf98e6512d5d188c31b6bd/main.cpp)
[CMakeLists.txt](/uploads/bcffb77482d5558f969d74c02eb32b26/CMakeLists.txt)Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25538make test errors after build on Mac2023-12-30T07:09:02-05:00Benjamin Gmake test errors after build on MacHello, I built cmake on a Mac (Mojave/10.14;Xcode 11.4.1) as part of the development environment I am building and got 6 failures during "make test". To simplify I am grouping into issues I think related and share what will like be thre...Hello, I built cmake on a Mac (Mojave/10.14;Xcode 11.4.1) as part of the development environment I am building and got 6 failures during "make test". To simplify I am grouping into issues I think related and share what will like be three issues total one at a time.
The first relates to failures that come up in "Architecture" and "BuildDepends" tests from an assumption that the Xcode GUI is installed and therefore "xcodebuild" works. If only the command line tools are installed, xcodebuild fails with:
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
In the context this seems like a heavyweight assumption since it is only being used to determine if Xcode V.3 versus V.4+ is installed and then only to determine whether the host supports targeting ppc, i386, and/or x86_64. I would offer alternate code for both tests but not sure which way you want to go.
Does Cmake V.3.28+ support host platforms running Xcode 4 (circa 2011-2013, likely Mac OS X Snow Leopard or maybe Lion) or even Xcode 3 (circa 2007-2011, likely Snow Leopard)? If no to Xcode 3, then seems like testing for it as a way to see if ppc is an available target is a moot point. Otherwise if assuming Mac OS X 10.10 or later as a minimum host platform, one can assume Xcode 6 tools and options are available. Or depending on the goals here, perhaps better to just build tests programs for different targets to see which work/error rather than trying to track which version of Xcode does what or even that the user is using Apple tools rather than GCC or LLVM?
Either way, I also think now would be time to update these tests to consider host platform that target arm64 as well as x86_64.https://gitlab.kitware.com/cmake/cmake/-/issues/25537MSVC: conflict preprocessor definition /DAMD64 /DARM64EC on ARM64EC2024-01-08T12:37:31-05:00Youmiu MoMSVC: conflict preprocessor definition /DAMD64 /DARM64EC on ARM64ECIn https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5708, adding the two definitions `AMD64` `ARM64EC` to a target `ARM64EC` causes conflict.
Given that these two tokens are common words, should this be circumvented? Or just remo...In https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5708, adding the two definitions `AMD64` `ARM64EC` to a target `ARM64EC` causes conflict.
Given that these two tokens are common words, should this be circumvented? Or just remove the non-underscored definitions?
`_M_ARM64EC` is [defined on target ARM64EC](https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170) for `MSVC`.
#### Example
https://github.com/microsoft/vcpkg-tool/blob/main/include/vcpkg/base/cofffilereader.h#L301-L304
https://github.com/microsoft/vcpkg-tool/blob/main/include/vcpkg/base/fwd/system.h#L11
#### Simplified
```C++
enum class MachineType
{
I386,
AMD64,
ARM,
ARM64,
ARM64EC,
};
```
#### Related
Modules/Platform/Windows-MSVC.cmake
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5708/diffs#5831acb5233d36fd9f14d82485726253780c4cbd_228_230
```CMake
if((_MSVC_C_ARCHITECTURE_FAMILY STREQUAL "ARM64EC") OR (_MSVC_CXX_ARCHITECTURE_FAMILY STREQUAL "ARM64EC"))
set(_PLATFORM_DEFINES "${_PLATFORM_DEFINES} /D_AMD64_ /DAMD64 /D_ARM64EC_ /DARM64EC /D_ARM64EC_WORKAROUND_")
endif()
```