CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-08-15T09:20:48-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16760cmGeneratorTarget::GetMacContentDirectory convert bool to enum parameter2017-08-15T09:20:48-04:00Gregor JasnycmGeneratorTarget::GetMacContentDirectory convert bool to enum parameter@craig.scott asked:
> Could also make a similar argument for `GetMacContentDirectory()` just below too. It might start a bit of a domino effect though, as then there's also the `SourceFileType` enum's `SourceFileTypeMacContent`.@craig.scott asked:
> Could also make a similar argument for `GetMacContentDirectory()` just below too. It might start a bit of a domino effect though, as then there's also the `SourceFileType` enum's `SourceFileTypeMacContent`.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16759VS2017: could not be found if installed in non-default location (Windows 7/8....2017-08-15T09:20:48-04:00HarpyWarVS2017: could not be found if installed in non-default location (Windows 7/8.1/2008)Just for note that the issue should be resolved.
The discussion was here https://cmake.org/pipermail/cmake/2017-March/065198.htmlJust for note that the issue should be resolved.
The discussion was here https://cmake.org/pipermail/cmake/2017-March/065198.htmlhttps://gitlab.kitware.com/cmake/cmake/-/issues/16757CMake tar command update capability2017-08-15T09:20:48-04:00MvdHurkCMake tar command update capabilityIt would be nice to have the capability to update a package (zip, tar, etc) with `cmake -E tar` command.It would be nice to have the capability to update a package (zip, tar, etc) with `cmake -E tar` command.https://gitlab.kitware.com/cmake/cmake/-/issues/16753Xcode: Add a source file property to control bundle destination section2020-11-08T07:36:35-05:00FletcherXcode: Add a source file property to control bundle destination sectionMost of my development is split between cross-platform C projects and Objective-C development for macOS. Using CMake to manage my C libraries makes it very easy to generate an Xcode project for my C libraries in order to readily incorpo...Most of my development is split between cross-platform C projects and Objective-C development for macOS. Using CMake to manage my C libraries makes it very easy to generate an Xcode project for my C libraries in order to readily incorporate them into larger macOS applications. It works great.
Except for one thing that really is driving me nuts.
Say I'm working on a project that creates the target `libFoo`. This requires the use of the header file `libFoo.h`. Normally, this will be referenced by the master project with `#include <libFoo/libFoo.h>`.
No problem, except that the CMake generated Xcode project requires me to manually do the following for it to work properly:
1. Select the desired target (`libFoo`)
2. Go to the "Build Phases" tab.
3. Add a new "Copy Files" phase.
4. Set Destination to "Products Directory"
5. Set Subpath to "include/${PRODUCT_NAME}"
6. Select `libFoo.h` and add it to the list of files.
7. Repeat if any other header files are required.
8. Repeat for each and every library I include this way
9. Repeat each and every time the Xcode project automatically gets regenerated when I happen to update the underlying library project with a new release with a git pull.
Until all that is done, I cannot use `#include <libFoo/libFoo.h>` in my master project.
Now, I *could* store the Xcode project in my git repo so that I don't have to repeat this. But then I have to manually update every time I add new files to the project, etc. This defeats the purpose of using CMake in the first place. It makes it hard to ensure that CMake and the Xcode project are both kept in a functional state as I continue development.
Questions/Requests
1. I have tried and tried, but cannot find a way do accomplish this automatically. If I missed something, please let me know.
2. If not, then please consider adding support for this. Support for `include/libFoo.h` seems present for other generators, and it should be supported in Xcode as well.
3. At the very least, it would be nice if CMake did not "clobber" changes like this that I make manually. I could live with doing this once. But doing it over and over and over gets tiring. ;)
Thank you!!
Fletcherhttps://gitlab.kitware.com/cmake/cmake/-/issues/16750Move CMAKE_HOST_SYSTEM_VERSION detection into cmStateSnapshot.cxx2017-08-15T09:20:48-04:00Gregor JasnyMove CMAKE_HOST_SYSTEM_VERSION detection into cmStateSnapshot.cxxCan the host system version be reliably extracted from the `uname(2)` structure like we do for the os name in 0bbd993f618e4ded1d949e64ba778dfab3106262? On Windows we already provide `CMAKE_HOST_SYSTEM_VERSION` via the C++ code during `E...Can the host system version be reliably extracted from the `uname(2)` structure like we do for the os name in 0bbd993f618e4ded1d949e64ba778dfab3106262? On Windows we already provide `CMAKE_HOST_SYSTEM_VERSION` via the C++ code during `EnableLanguage`. That could be moved to the same place we set `CMAKE_HOST_SYSTEM_NAME` so that `CMAKE_HOST_SYSTEM_VERSION` is available in scripting context, and on all platforms.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16739iOS framework headers doesn't preserve folder hierarchy2023-04-19T05:43:03-04:00Robert BielikiOS framework headers doesn't preserve folder hierarchyIf I have a include header hierarchy as follows:
```
.
└── mylib
├── header.h - My libs header
├── header2.h
└── service
└── header.h - A header with same name as in folder above
```
and use:
```
SET(MY_HEADE...If I have a include header hierarchy as follows:
```
.
└── mylib
├── header.h - My libs header
├── header2.h
└── service
└── header.h - A header with same name as in folder above
```
and use:
```
SET(MY_HEADERS
mylib/header.h
mylib/header2.h
mylib/service/header.h
)
SET_TARGET_PROPERTIES(mylibtarget
PROPERTIES
FRAMEWORK TRUE
MACOSX_RPATH ON
...
PUBLIC_HEADER "${MY_HEADERS}"
...
)
```
I end up with a framework that has following structure:
```
.
└── mylib.framework
├── Headers
│ ├── header.h
│ └── header2.h
├── Info.plist
└── mylib
```
i.e. the root include hierarchy has been flattened, and not only that, the header.h in the framework is the "last" header.h in the include, the one in the **service** subfolder !! What I of course really should have is:
```
.
└── mylib.framework
├── Headers
│ ├── header.h
│ ├── header2.h
│ └── service
│ └── header.h
├── Info.plist
└── mylib
```
This is with cmake 3.7.1 on Mac OS X 10.11.6 and Xcode 8.2.1.Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16731Ninja: response files not supported by `ar` on macOS2021-07-22T05:25:18-04:00Brad KingNinja: response files not supported by `ar` on macOSWhen using `CMAKE_NINJA_FORCE_RESPONSE_FILE` or creating a very large archive, the Ninja generator produces a response file rule. However, `ar` on macOS does not support response files.
Fixing this will require the Ninja generator to t...When using `CMAKE_NINJA_FORCE_RESPONSE_FILE` or creating a very large archive, the Ninja generator produces a response file rule. However, `ar` on macOS does not support response files.
Fixing this will require the Ninja generator to thread through information about what tool is being used and whether it supports response files. Also, in order to generate large archives on macOS without using response files we will need to resolve the existing TODO comment in the Ninja generator about using `ARCHIVE_APPEND` rules.https://gitlab.kitware.com/cmake/cmake/-/issues/16730Clang support in Visual Studio 20172017-10-13T13:17:55-04:00Mikhail PilinClang support in Visual Studio 2017There is the new experimental toolset name `v141_clang_c2` to activate clang compiler in VS2017.
Could you please and support for that?
P.S VS2017 support two versions of std libraries: GNU and Clang.There is the new experimental toolset name `v141_clang_c2` to activate clang compiler in VS2017.
Could you please and support for that?
P.S VS2017 support two versions of std libraries: GNU and Clang.https://gitlab.kitware.com/cmake/cmake/-/issues/16725file(GENERATE OUTPUT some_name INPUT some_name.tmp) deletes the input file2022-01-31T04:44:45-05:00Kai Pastorfile(GENERATE OUTPUT some_name INPUT some_name.tmp) deletes the input fileWhen using `file(GENERATE OUTPUT ...cmake INPUT ...cmake.tmp)`, CMake deletes the input file after the generation step.
- This behaviour is surprising and undocumented.
- If the input file is created via `configure_file()`, CMake is re...When using `file(GENERATE OUTPUT ...cmake INPUT ...cmake.tmp)`, CMake deletes the input file after the generation step.
- This behaviour is surprising and undocumented.
- If the input file is created via `configure_file()`, CMake is re-run on every build due to the missing dependency ("Re-run cmake, missing byproduct: ...cmake.tmp"). This is how I found this issue: make install after make triggered an unexpected re-run of CMake.
The issue does not occur when the input file does not end in `...cmake.tmp`.
[CMakeLists.txt](/uploads/9a193c57850aed588675e5dbfc8fa781/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/16724find_package( HDF5 ) doesn't respect CMAKE_FIND_ROOT_PATH_MODE_PACKAGE2017-10-13T13:17:55-04:00mattgruenkefind_package( HDF5 ) doesn't respect CMAKE_FIND_ROOT_PATH_MODE_PACKAGEWhile trying to cross-compile flann-1.8.4 for Android, I've encountered the following quagmire:
* Flann uses find_package( HDF5 ), but it's not required & I don't have it on the target system.
* This finds the package installed on the...While trying to cross-compile flann-1.8.4 for Android, I've encountered the following quagmire:
* Flann uses find_package( HDF5 ), but it's not required & I don't have it on the target system.
* This finds the package installed on the host, unless CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is set to ONLY (no matter what CMAKE_FIND_ROOT_PATH_MODE_PACKAGE says).
* However, when I set CMAKE_FIND_ROOT_PATH_MODE_PROGRAM to ONLY, CMake no longer finds the NDK's ar program (static linker).
* Even if I explicitly set CMAKE_AR, its value isn't respected, and the static linking command ends up as "".
It seems to me like there's one or two bugs, here. First, find_package() should respect CMAKE_FIND_ROOT_PATH_MODE_PACKAGE and be unaffected by CMAKE_FIND_ROOT_PATH_MODE_PROGRAM. That much seems clear.
Secondly, I don't understand why CMAKE_FIND_ROOT_PATH_MODE_PROGRAM is breaking CMake's ability to find ar, not least because ar is installed in one of the directories listed in my CMAKE_FIND_ROOT_PATH. I double & triple-checked all my path strings, to make sure it's not just a typo somewhere. I'll reproduce & file this as a separate bug.
Attached is the output of CMake finding HDF5 on the host system, then trying to use it during cross-compilation. Toolchain file also included. Though I think the issue is probably a bug in `share/cmake-3.7/Modules/FindHDF5.cmake`, rather than anything specific to flann, it can be obtained from http://www.cs.ubc.ca/research/flann/
[toolchain_android.cmake](/uploads/e7f23ecc41cb9de3218510ee2441cc82/toolchain_android.cmake)
[flann-1.8.4_build.log](/uploads/161aae033dc75b783c574f73e9c4ae84/flann-1.8.4_build.log)https://gitlab.kitware.com/cmake/cmake/-/issues/16723IFW Generator: Hierarchy is not preserved in maintenance tool for groups that...2021-10-18T04:53:49-04:00Daniele E. DomenichelliIFW Generator: Hierarchy is not preserved in maintenance tool for groups that are not installedIn online installers created using the IFW generator, group hierarchy is not preserved in the maintenance tool for groups that are not installed.
Steps to reproduce: create the installer, install only the components from one group, run ...In online installers created using the IFW generator, group hierarchy is not preserved in the maintenance tool for groups that are not installed.
Steps to reproduce: create the installer, install only the components from one group, run the maintenance tool in the installation directory.
This is a minimal example to show the issue.
```cmake
cmake_minimum_required(VERSION 3.5)
project(test_installer NONE)
# Force IFW generator
set(CPACK_GENERATOR IFW)
# If not set, all components will be merged in the group
set(CPACK_COMPONENTS_GROUPING IGNORE)
if(WIN32 AND CMAKE_GENERATOR MATCHES "^Visual Studio")
if(CMAKE_GENERATOR_PLATFORM MATCHES "x64" OR CMAKE_GENERATOR MATCHES "Win64")
string(APPEND CPACK_SYSTEM_NAME x86_amd64)
elseif(NOT CMAKE_GENERATOR MATCHES "ARM")
string(APPEND CPACK_SYSTEM_NAME x86)
endif()
endif()
set(CPACK_IFW_PACKAGE_GROUP root)
include(CPack)
include(CPackIFW)
# Add root component
cpack_add_component_group(root EXPANDED)
cpack_ifw_configure_component_group(root NAME org.foo.installer)
# Add some groups
foreach(_g g1 g2 g3)
cpack_add_component_group(${_g} PARENT_GROUP root)
cpack_ifw_configure_component_group(${_g} NAME org.foo.installer.${_g})
foreach(_f a b c d)
# Add some components
file(WRITE "${CMAKE_BINARY_DIR}/${_g}/${_f}.txt" "${_f}.txt contents\n")
install(FILES "${CMAKE_BINARY_DIR}/${_g}/${_f}.txt"
DESTINATION ${_g}
COMPONENT ${_g}_${_f})
cpack_add_component(${_g}_${_f}
DISABLED
GROUP ${_g}
DOWNLOADED)
cpack_ifw_configure_component(${_g}_${_f} NAME org.foo.installer.${_g}.${_f})
endforeach()
endforeach()
# Configure the repository
cpack_ifw_add_repository(repo URL "file:///${CMAKE_BINARY_DIR}/_CPack_Packages/${CPACK_SYSTEM_NAME}/IFW/${CPACK_PACKAGE_NAME}-${CPACK_PACKAGE_VERSION}-${CPACK_SYSTEM_NAME}/repository")
```Konstantin PodsvirovKonstantin Podsvirovhttps://gitlab.kitware.com/cmake/cmake/-/issues/16721CPACK_RPM_DEBUGINFO_PACKAGE =on + CPACK_RPM_${COMPONENT}_DEBUGINFO_PACKAGE=OF...2017-10-13T13:17:55-04:00Daniel BlackCPACK_RPM_DEBUGINFO_PACKAGE =on + CPACK_RPM_${COMPONENT}_DEBUGINFO_PACKAGE=OFF still builds debuginfo for componentsmall feature request. Should be possible to disable a small number of components.small feature request. Should be possible to disable a small number of components.Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16720In generated Visual Studio projects, the Release config has /INCREMENTAL:NO b...2020-06-10T07:05:22-04:00Tom SeddonIn generated Visual Studio projects, the Release config has /INCREMENTAL:NO but RelWithDebInfo has /INCREMENTAL:YESThe only difference between Release and RelWithDebInfo should be the debug info status, surely?
Presumably RelWithDebInfo should link non-incrementally, rather than Release linking incrementally...
Thanks,
--TomThe only difference between Release and RelWithDebInfo should be the debug info status, surely?
Presumably RelWithDebInfo should link non-incrementally, rather than Release linking incrementally...
Thanks,
--Tomhttps://gitlab.kitware.com/cmake/cmake/-/issues/16719Visual Studio generators create VC project files even if the solution only ha...2017-10-13T13:17:55-04:00Javier MartínVisual Studio generators create VC project files even if the solution only has enabled FortranWhen generating Visual Studio solutions and project files for a Fortran-only project, CMake correctly creates `.vfproj` project files for the binary targets, but any other targets (like custom targets or support targets like install) are...When generating Visual Studio solutions and project files for a Fortran-only project, CMake correctly creates `.vfproj` project files for the binary targets, but any other targets (like custom targets or support targets like install) are generated as `.vcproj` files for Visual C/C++. This makes those projects unusable if Visual C++ is not installed, and in some VS versions it can also cause a crash on build.
In particular, with Intel Fortran 12.0 installed with the Visual Studio 2008 "shell only" (that is, without VC++), the VS shell cannot load the "support projects" `ALL_BUILD`, `INSTALL` and `ZERO_CHECK`. Since _all_ projects depend on the latter, this appears to trigger some bug in VS2008 that crashes the VS shell. I guess that in other versions of VS, it will simply refuse to build because a project depends on another that is not (and cannot be) loaded.
The root cause is that the choice of the project type depends on `cmGlobalVisualStudioGenerator::TargetIsFortranOnly(cmGeneratorTarget const*)`, which returns true if and only if the target in question has a single language enabled and that language is Fortran. However, the "support" projects mentioned above have _no_ languages enabled at all, so CMake falls back to the default of creating a VC++ project.
I propose a patch with a simple solution: since Fortran projects can also carry custom actions, `TargetIsFortranOnly` should *also* return true if the target has no languages enabled _but_ the overall CMake project has enabled only Fortran (ignoring RC, the resource compiler). Thus, for a project which only has Fortran enabled, the "support" targets would be created as `.vfproj` files, while for a mixed C/Fortran project (or for a project without Fortran) the current `.vcproj` default would be kept.
[cmake-vfproj.patch](/uploads/36a8fdf523ef2038e842ed5e400219a1/cmake-vfproj.patch)https://gitlab.kitware.com/cmake/cmake/-/issues/16716Support for version suffixes2023-04-12T02:38:29-04:00Roger LeighSupport for version suffixes# Summary
CMake versions currently use a `major.minor[.patch[.tweak]]` pattern, with this usage mandated by:
- `cmake_minimum_required`
- `cmake_policy`
- `find_package` (and `PACKAGE_FIND_VERSION_*` and `<package>_VERSION_*` and...# Summary
CMake versions currently use a `major.minor[.patch[.tweak]]` pattern, with this usage mandated by:
- `cmake_minimum_required`
- `cmake_policy`
- `find_package` (and `PACKAGE_FIND_VERSION_*` and `<package>_VERSION_*` and `<package>_FIND_VERSION_*`)
- `if` with `VERSION_LESS`, `VERSION_EQUAL` and `VERSION_GREATER`
- `project` (and `PROJECT_VERSION_*` and `<project>_VERSION_*`)
- variables `CMAKE_*_VERSION`, `CMAKE_[*-]SYSTEM_VERSION`
While this works well in most cases, it does not permit the use of informational suffixes which creates a barrier for interoperability and integration with projects which do. Would it be possible to consider changing the pattern to `major.minor[.patch[.tweak]][suffix]` to allow the use of a non-numerical suffix? This could be accompanied by the addition of corresponding `_VERSION_SUFFIX` variables to complement the existing numerical ones.
# Rationale
There are several use cases:
1. Projects already using version suffixes in their workflows, to pass to `project()`:
* `-DEV`, `-DEV-${gitshortversion}`, `-beta3`, -`rc2` etc. Indicate and communicate that the version is an unreleased work in progress, or not a final release, [possibly dynamically](https://github.com/ome/ome-common-cpp/blob/v5.4.0/cmake/Version.cmake) depending on the presence or absence of a suitable git tag
* `-SNAPSHOT` (for interoperability with maven, when a mixed Java and C++ codebase--[example](https://github.com/ome/ome-model/blob/v5.5.2/cmake/MavenVersion.cmake))
* Currently we hack both of these in by hand but it doesn't integrate with cmake's versioning in any way e.g. for packaging, target version properties, exported configuration etc.
2. Third party libraries with `find_package`:
* `1.0.2g` (openssl)
3. Version comparison of versions with suffixes using `if`
* for use in find_package with third-party versioning conventions
* could potentially consider the versions using an established convention such as the [Debian version comparison algorithm](http://www.fifi.org/doc/debian-policy/policy.html/ch-versions.html) minus the epoch and debian revision parts.
* alternatively could remain the same and ignore suffixes entirely, treating them as informational only
# Implementation
- Would need a modification or alternative to `cmSystemTools::VersionCompare`
- Updates to a handful of source files to add the extra variables
- Corresponding docs updates
- Most existing uses of versions will require no change; the changes would all be backward compatible since the suffix is an optional addition
Has such a change been proposed before? I would certainly not want to discourage correct use of four digit or three digit semver-style versioning by cmake or any projects using it. This proposal is primarily to aid interoperability with projects not using these conventions or where the versioning conventions are imposed by other tooling but which we have to deal with. Additionally, using the suffix for project versioning is useful in communicating the development or release status of the source in the absence of e.g. a git tag, or in a source archive lacking a tag.
If such a change would be considered acceptable, I'd be happy to work on the implementation.
Kind regards,
Rogerhttps://gitlab.kitware.com/cmake/cmake/-/issues/16714Using Intel Fortran on Windows with NMake generator fails to detect the linke...2017-10-13T13:17:55-04:00Javier MartínUsing Intel Fortran on Windows with NMake generator fails to detect the linker versionWhen using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS20...When using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS2008, so the linker used is able to generate and embed a manifest into binaries. However, since the activation of this feature depends on MSVC_VERSION and this variable gets a "wrong", low value, the manifest embedding is not enabled and instead, the linker generates both my out.exe and an out.exe.manifest file. By contrast, if the VS 2008 generator is used instead of the "NMake Makefiles" generator, the rules for manifest embedding are generated.
The problem can be reproduced as follows:
* Environment: Windows computer with Intel Fortran 12.0 with MS Visual Studio 2008 _shell_ - it has link.exe (9.0) but not the corresponding cl.exe (15.0)
* Project: any simple "hello world" Fortran project will do. I am just doing `project(out Fortran)` and then `add_executable(out hello.f90)`.
* Configuration: I configure and generate the project with two generators, "Visual Studio 9 2008" and "NMake Makefiles" (the latter from the command line created by the Intel Fortran-provided equivalent to vcvars.bat)
* Result: the VS project generates out.exe, which has an embedded manifest; while the makefile version generates out.exe _without_ an embedded manifest _and_ an out.exe.manifest alongside it. In order for the latter executable to be usable, the manifest file must either be copied alongside the binary, or manually embedded with a call to mt.exe.
* Expected result: both generators result in executable files with embedded manifests.
I traced the problem to the fact that `Modules/Platforms/Windows-MSVC.cmake` (which is included by `Windows-Intel.cmake`) tests the `MSVC_VERSION` variable (the version of *cl.exe*) and only enables the manifest embedding if it at least 1400, the version of cl that comes with VS 2005.
This variable is defined above in the same file; in this case it is set from the value of the `CMAKE_Fortran_SIMULATE_VERSION` variable, which comes from data extracted from the Intel Fortran compiler by building and running `CMakeFortranCompilerId.F.in`. The problem is that, while Intel Fortran in Windows does report the \_MSC_VER macro, it reports *the same version reported by cl.exe*. Since in my case there is no cl.exe to be found, ifort reports _MSC_VER=1020, which is so old that it is stored by CMake as 1300. Thus, the manifest embedding feature is not enabled.
Since having the Intel Fortran compiler without the MS _C compiler_ is a valid configuration, the condition for the manifest embedding feature should depend on detecting features from the linker itself, not the C compiler.https://gitlab.kitware.com/cmake/cmake/-/issues/16705cpack: wrong directory permissions of automatically created directories in d...2017-10-13T13:17:55-04:00Bernicpack: wrong directory permissions of automatically created directories in deb build.When building a deb-package the permissions of directories should be 755 according do debian standard but they are 770 if the directories are automatically added. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}.When building a deb-package the permissions of directories should be 755 according do debian standard but they are 770 if the directories are automatically added. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}.https://gitlab.kitware.com/cmake/cmake/-/issues/16704FindPkgConfig: Missing dev package but CMake does't print which is missing2017-10-13T13:17:55-04:00Szőgyényi GáborFindPkgConfig: Missing dev package but CMake does't print which is missing**Compiling evolution the build fails with this CMake error log:**
```
Performing C SOURCE FILE Test c_flag_-no-undefined_supported failed with the following output:
Change Dir: /home/szg/evolution/build/CMakeFiles/CMakeTmp
Run B...**Compiling evolution the build fails with this CMake error log:**
```
Performing C SOURCE FILE Test c_flag_-no-undefined_supported failed with the following output:
Change Dir: /home/szg/evolution/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_00a69/fast"
/usr/bin/make -f CMakeFiles/cmTC_00a69.dir/build.make CMakeFiles/cmTC_00a69.dir/build
make[1]: Entering directory '/home/szg/evolution/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_00a69.dir/src.c.o
/usr/bin/cc -Werror-implicit-function-declaration -Wformat -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-noreturn -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -Dc_flag_-no-undefined_supported -fPIE -no-undefined -o CMakeFiles/cmTC_00a69.dir/src.c.o -c /home/szg/evolution/build/CMakeFiles/CMakeTmp/src.c
cc: error: unrecognized command line option '-no-undefined'; did you mean '-Wno-undef'?
CMakeFiles/cmTC_00a69.dir/build.make:65: recipe for target 'CMakeFiles/cmTC_00a69.dir/src.c.o' failed
make[1]: *** [CMakeFiles/cmTC_00a69.dir/src.c.o] Error 1
make[1]: Leaving directory '/home/szg/evolution/build/CMakeFiles/CMakeTmp'
Makefile:126: recipe for target 'cmTC_00a69/fast' failed
make: *** [cmTC_00a69/fast] Error 2
Source file was:
int main(void) { return 0; }
Performing C SOURCE FILE Test c_flag_-Wno-missing-include-dir_supported failed with the following output:
Change Dir: /home/szg/evolution/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_1c791/fast"
/usr/bin/make -f CMakeFiles/cmTC_1c791.dir/build.make CMakeFiles/cmTC_1c791.dir/build
make[1]: Entering directory '/home/szg/evolution/build/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_1c791.dir/src.c.o
/usr/bin/cc -Werror-implicit-function-declaration -Wformat -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-noreturn -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -fno-strict-aliasing -Wno-deprecated-declarations -Dc_flag_-Wno-missing-include-dir_supported -fPIE -Wno-missing-include-dir -o CMakeFiles/cmTC_1c791.dir/src.c.o -c /home/szg/evolution/build/CMakeFiles/CMakeTmp/src.c
<command-line>:0:8: warning: ISO C99 requires whitespace after the macro name
cc1: warning: unrecognized command line option '-Wno-missing-include-dir'
Linking C executable cmTC_1c791
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_1c791.dir/link.txt --verbose=1
/usr/bin/cc -Werror-implicit-function-declaration -Wformat -Wformat-security -Winit-self -Wmissing-declarations -Wmissing-noreturn -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -fno-strict-aliasing -Wno-deprecated-declarations -Dc_flag_-Wno-missing-include-dir_supported CMakeFiles/cmTC_1c791.dir/src.c.o -o cmTC_1c791 -rdynamic
make[1]: Leaving directory '/home/szg/evolution/build/CMakeFiles/CMakeTmp'
Source file was:
int main(void) { return 0; }
```
**The build printout doest discribe which dev package is missing:**
```console
szg@debian:~/evolution$ mkdir build
szg@debian:~/evolution$ cd build/
szg@debian:~/evolution/build$ cmake -DENABLE_GNOME_DESKTOP=OFF -DWITH_OPENLDAP=OFF -G "Unix Makefiles" ..
-- The C compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Found Gettext: /usr/bin/msgmerge (found version "0.19.8.1")
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.29")
-- Performing Test c_flag_-Werror-implicit-function-declaration_supported
-- Performing Test c_flag_-Werror-implicit-function-declaration_supported - Success
-- Performing Test c_flag_-Wformat_supported
-- Performing Test c_flag_-Wformat_supported - Success
-- Performing Test c_flag_-Wformat-security_supported
-- Performing Test c_flag_-Wformat-security_supported - Success
-- Performing Test c_flag_-Winit-self_supported
-- Performing Test c_flag_-Winit-self_supported - Success
-- Performing Test c_flag_-Wmissing-declarations_supported
-- Performing Test c_flag_-Wmissing-declarations_supported - Success
-- Performing Test c_flag_-Wmissing-noreturn_supported
-- Performing Test c_flag_-Wmissing-noreturn_supported - Success
-- Performing Test c_flag_-Wpointer-arith_supported
-- Performing Test c_flag_-Wpointer-arith_supported - Success
-- Performing Test c_flag_-Wredundant-decls_supported
-- Performing Test c_flag_-Wredundant-decls_supported - Success
-- Performing Test c_flag_-Wundef_supported
-- Performing Test c_flag_-Wundef_supported - Success
-- Performing Test c_flag_-Wwrite-strings_supported
-- Performing Test c_flag_-Wwrite-strings_supported - Success
-- Performing Test c_flag_-no-undefined_supported
-- Performing Test c_flag_-no-undefined_supported - Failed
-- Performing Test c_flag_-fno-strict-aliasing_supported
-- Performing Test c_flag_-fno-strict-aliasing_supported - Success
-- Performing Test c_flag_-Wno-deprecated-declarations_supported
-- Performing Test c_flag_-Wno-deprecated-declarations_supported - Success
-- Performing Test c_flag_-Wno-missing-include-dir_supported
-- Performing Test c_flag_-Wno-missing-include-dir_supported - Failed
-- Performing Test c_flag_-Wdeclaration-after-statement_supported
-- Performing Test c_flag_-Wdeclaration-after-statement_supported - Success
-- Performing Test c_flag_-Wno-missing-field-initializers_supported
-- Performing Test c_flag_-Wno-missing-field-initializers_supported - Success
-- Performing Test c_flag_-Wno-sign-compare_supported
-- Performing Test c_flag_-Wno-sign-compare_supported - Success
-- Performing Test c_flag_-Wno-unused-parameter_supported
-- Performing Test c_flag_-Wno-unused-parameter_supported - Success
-- Performing Test c_flag_-Wnested-externs_supported
-- Performing Test c_flag_-Wnested-externs_supported - Success
-- Looking for sys/wait.h
-- Looking for sys/wait.h - found
-- Looking for X11/XF86keysym.h
-- Looking for X11/XF86keysym.h - found
-- Looking for mkdtemp
-- Looking for mkdtemp - found
-- Looking for nl_langinfo
-- Looking for nl_langinfo - found
-- Performing Test HAVE__NL_MEASUREMENT_MEASUREMENT
-- Performing Test HAVE__NL_MEASUREMENT_MEASUREMENT - Success
-- Checking for modules 'cairo-gobject;gail-3.0>=3.10;gcr-3>=3.4;gdk-pixbuf-2.0>=2.24.0;gio-2.0>=2.46;gio-unix-2.0;gmodule-2.0>=2.46;gsettings-desktop-schemas>=2.91.92;gtk+-3.0>=3.10;libxml-2.0>=2.7.3;shared-mime-info>=0.22;webkit2gtk-4.0>=2.13.90'
--
--
--
--
CMake Error at /usr/share/cmake-3.7/Modules/FindPkgConfig.cmake:415 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.7/Modules/FindPkgConfig.cmake:588 (_pkg_check_modules_internal)
CMakeLists.txt:259 (pkg_check_modules)
-- Configuring incomplete, errors occurred!
See also "/home/szg/evolution/build/CMakeFiles/CMakeOutput.log".
See also "/home/szg/evolution/build/CMakeFiles/CMakeError.log".
szg@debian:~/evolution/build$
```https://gitlab.kitware.com/cmake/cmake/-/issues/16699Auto add Boost::dynamic_linking when needed2017-10-13T13:17:54-04:00Bill HoffmanAuto add Boost::dynamic_linking when neededWould it be possible to automatically make Boost::dynamic_linking a public link depend of boost libraries if we determine that the boost libraries we are linking are dynamic? Since CMake only finds one version of the boost libraries and...Would it be possible to automatically make Boost::dynamic_linking a public link depend of boost libraries if we determine that the boost libraries we are linking are dynamic? Since CMake only finds one version of the boost libraries and it will be either dynamic or not, seems like people should not have to specify Boost::dynamic_linking by hand as it will not work without it. @rleigh thoughts?https://gitlab.kitware.com/cmake/cmake/-/issues/16698Clarify documentation on creating imported targets for Windows shared libraries2019-11-11T11:25:31-05:00Dick AnnicchiaricoClarify documentation on creating imported targets for Windows shared librariesI am writing a simple CMake file which is building a shared library. The library depends on 3 other shared libraries so it has to link against those libraries. They are external libraries, i.e. **not** a target of the CMake. I am havi...I am writing a simple CMake file which is building a shared library. The library depends on 3 other shared libraries so it has to link against those libraries. They are external libraries, i.e. **not** a target of the CMake. I am having trouble defining this properly. When I do it the way I **think** I should be doing it, I always get CMake doing links where it is obvious that it has not resolved the library location because it will have modules like "aws-cpp-sdk-core-NOTFOUND" on the link command line. I found a way to get it to work (shown here) but it is platform-dependent (Windows) and doesn't seem like the right solution. Seems like I am missing something basic -- can someone help?
```
CMAKE_MINIMUM_REQUIRED(VERSION 3.7)
PROJECT(ICOSProvider)
INCLUDE_DIRECTORIES($ENV{AWS_SRC_DIR}/aws-cpp-sdk-core/include $ENV{AWS_SRC_DIR}/aws-cpp-sdk-s3/include $ENV{NOTESINC})
ADD_LIBRARY(ICOSProvider SHARED ICOSProvider.cpp)
# This project requires the AWS core and S3 libraries.
#ADD_LIBRARY(aws-cpp-sdk-core SHARED IMPORTED)
#SET_PROPERTY(TARGET aws-cpp-sdk-core PROPERTY IMPORTED_LOCATION $ENV{AWS_BIN_DIR}/aws-cpp-sdk-core)
#ADD_LIBRARY(aws-cpp-sdk-s3 SHARED IMPORTED)
#SET_PROPERTY(TARGET aws-cpp-sdk-s3 PROPERTY IMPORTED_LOCATION $ENV{AWS_BIN_DIR}/aws-cpp-sdk-s3)
#ADD_LIBRARY(nnotes SHARED IMPORTED)
#SET_PROPERTY(TARGET nnotes PROPERTY IMPORTED_LOCATION $ENV{NOTESLIB})
#TARGET_LINK_LIBRARIES(ICOSProvider aws-cpp-sdk-core aws-cpp-sdk-s3 nnotes)
#
# This works by itself, but doesn't seem to be the right way to do things. I've tried various stuff including the
# statements commented out immediately above, but can't get it quite right.
#
TARGET_LINK_LIBRARIES(ICOSProvider $ENV{AWS_BIN_DIR}/aws-cpp-sdk-core/Debug/aws-cpp-sdk-core.lib $ENV{AWS_BIN_DIR}/aws-cpp-sdk-s3/Debug/aws-cpp-sdk-s3.lib $ENV{NOTESLIB}/nnotes.lib)
```