CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-05-26T11:17:20-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16893Ninja generator doesn’t work in msys2-built cmake2017-05-26T11:17:20-04:00Norbert PfeilerNinja generator doesn’t work in msys2-built cmakeThe problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to...The problem doesn’t appear with the official binaries.
corresponding issue: https://github.com/Alexpux/MINGW-packages/issues/2462
The Ninja generator uses a codecvt to generate ANSI output.
This codecvt however doesn’t appear to work with mingw-w64 which results in an inability for the generator to produce any files.
`codecvt::do_out` always returns `std::codecvt::error` when a range of more than 1 char is passed.
Changing [this condition](https://gitlab.kitware.com/cmake/cmake/blob/6b05e028f1a3afc7906908bd48d58993da02a9d9/Source/cm_codecvt.cxx#L61) to `>= 1` seems to fix it.
I’m not sure why it should work the way it currently is at all.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16887RunCMake.GNUInstallDirs test fails on FreeBSD2017-06-09T11:04:04-04:00François BisseyRunCMake.GNUInstallDirs test fails on FreeBSDIt fails because `CMAKE_INSTALL_MANDIR` is `man` not `share/man` similarly with `CMAKE_INSTALL_FULL_MANDIR`. Typical error output
```
298: expect-err> ^CMAKE_INSTALL_BINDIR='bin'
298: expect-err> CMAKE_INSTALL_DATADIR='share'
298: ...It fails because `CMAKE_INSTALL_MANDIR` is `man` not `share/man` similarly with `CMAKE_INSTALL_FULL_MANDIR`. Typical error output
```
298: expect-err> ^CMAKE_INSTALL_BINDIR='bin'
298: expect-err> CMAKE_INSTALL_DATADIR='share'
298: expect-err> CMAKE_INSTALL_DATAROOTDIR='share'
298: expect-err> CMAKE_INSTALL_DOCDIR='share/doc/UsrLocal'
298: expect-err> CMAKE_INSTALL_INCLUDEDIR='include'
298: expect-err> CMAKE_INSTALL_INFODIR='share/info'
298: expect-err> CMAKE_INSTALL_LIBDIR='(lib|lib64)'
298: expect-err> CMAKE_INSTALL_LIBEXECDIR='libexec'
298: expect-err> CMAKE_INSTALL_LOCALEDIR='share/locale'
298: expect-err> CMAKE_INSTALL_LOCALSTATEDIR='var'
298: expect-err> CMAKE_INSTALL_MANDIR='share/man'
298: expect-err> CMAKE_INSTALL_SBINDIR='sbin'
298: expect-err> CMAKE_INSTALL_SHAREDSTATEDIR='com'
298: expect-err> CMAKE_INSTALL_SYSCONFDIR='etc'
298: expect-err> CMAKE_INSTALL_FULL_BINDIR='/usr/local/bin'
298: expect-err> CMAKE_INSTALL_FULL_DATADIR='/usr/local/share'
298: expect-err> CMAKE_INSTALL_FULL_DATAROOTDIR='/usr/local/share'
298: expect-err> CMAKE_INSTALL_FULL_DOCDIR='/usr/local/share/doc/UsrLocal'
298: expect-err> CMAKE_INSTALL_FULL_INCLUDEDIR='/usr/local/include'
298: expect-err> CMAKE_INSTALL_FULL_INFODIR='/usr/local/share/info'
298: expect-err> CMAKE_INSTALL_FULL_LIBDIR='/usr/local/(lib|lib64)'
298: expect-err> CMAKE_INSTALL_FULL_LIBEXECDIR='/usr/local/libexec'
298: expect-err> CMAKE_INSTALL_FULL_LOCALEDIR='/usr/local/share/locale'
298: expect-err> CMAKE_INSTALL_FULL_LOCALSTATEDIR='/usr/local/var'
298: expect-err> CMAKE_INSTALL_FULL_MANDIR='/usr/local/share/man'
298: expect-err> CMAKE_INSTALL_FULL_SBINDIR='/usr/local/sbin'
298: expect-err> CMAKE_INSTALL_FULL_SHAREDSTATEDIR='/usr/local/com'
298: expect-err> CMAKE_INSTALL_FULL_SYSCONFDIR='/usr/local/etc'$
298:
298: Actual stderr:
298:
298: actual-err> CMAKE_INSTALL_BINDIR='bin'
298: actual-err> CMAKE_INSTALL_DATADIR='share'
298: actual-err> CMAKE_INSTALL_DATAROOTDIR='share'
298: actual-err> CMAKE_INSTALL_DOCDIR='share/doc/UsrLocal'
298: actual-err> CMAKE_INSTALL_INCLUDEDIR='include'
298: actual-err> CMAKE_INSTALL_INFODIR='info'
298: actual-err> CMAKE_INSTALL_LIBDIR='lib'
298: actual-err> CMAKE_INSTALL_LIBEXECDIR='libexec'
298: actual-err> CMAKE_INSTALL_LOCALEDIR='share/locale'
298: actual-err> CMAKE_INSTALL_LOCALSTATEDIR='var'
298: actual-err> CMAKE_INSTALL_MANDIR='man'
298: actual-err> CMAKE_INSTALL_SBINDIR='sbin'
298: actual-err> CMAKE_INSTALL_SHAREDSTATEDIR='com'
298: actual-err> CMAKE_INSTALL_SYSCONFDIR='etc'
298: actual-err> CMAKE_INSTALL_FULL_BINDIR='/usr/local/bin'
298: actual-err> CMAKE_INSTALL_FULL_DATADIR='/usr/local/share'
298: actual-err> CMAKE_INSTALL_FULL_DATAROOTDIR='/usr/local/share'
298: actual-err> CMAKE_INSTALL_FULL_DOCDIR='/usr/local/share/doc/UsrLocal'
298: actual-err> CMAKE_INSTALL_FULL_INCLUDEDIR='/usr/local/include'
298: actual-err> CMAKE_INSTALL_FULL_INFODIR='/usr/local/info'
298: actual-err> CMAKE_INSTALL_FULL_LIBDIR='/usr/local/lib'
298: actual-err> CMAKE_INSTALL_FULL_LIBEXECDIR='/usr/local/libexec'
298: actual-err> CMAKE_INSTALL_FULL_LOCALEDIR='/usr/local/share/locale'
298: actual-err> CMAKE_INSTALL_FULL_LOCALSTATEDIR='/usr/local/var'
298: actual-err> CMAKE_INSTALL_FULL_MANDIR='/usr/local/man'
298: actual-err> CMAKE_INSTALL_FULL_SBINDIR='/usr/local/sbin'
298: actual-err> CMAKE_INSTALL_FULL_SHAREDSTATEDIR='/usr/local/com'
298: actual-err> CMAKE_INSTALL_FULL_SYSCONFDIR='/usr/local/etc'
```3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16800CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH is interpreted differently if coming fr...2017-05-03T10:50:22-04:00Åke SandgrenCMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH is interpreted differently if coming from the environment compared to being set with -DCMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH are defined as ";-list of directories specifying a search path" in the documentation.
When doing
cmake -DCMAKE_INCLUDE_PATH='/patha;/pathb'
it behaves as expected.
But when set in the enviroment it...CMAKE_INCLUDE_PATH/CMAKE_LIBRARY_PATH are defined as ";-list of directories specifying a search path" in the documentation.
When doing
cmake -DCMAKE_INCLUDE_PATH='/patha;/pathb'
it behaves as expected.
But when set in the enviroment it doesn't. It doesn't get split on ";", instead it gets split on ":"
Having two different interpretations of those variables (and others) is confusing, especially since it doesn't seem to be documented anywhere.
Is there a reason NOT to split on ";" even when coming from the environment?3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16795Xcode generator doesn't respect SYSTEM when setting include_directories2017-04-22T11:04:29-04:00Konstantin KäferXcode generator doesn't respect SYSTEM when setting include_directoriesWhen using `target_include_directories(target SYSTEM <paths...>)`, the Make and Ninja generators use `-isystem` to pass the include directories to the compiler. Xcode has the properties `HEADER_SEARCH_PATHS` (which get passed with `-I` t...When using `target_include_directories(target SYSTEM <paths...>)`, the Make and Ninja generators use `-isystem` to pass the include directories to the compiler. Xcode has the properties `HEADER_SEARCH_PATHS` (which get passed with `-I` to the compiler), and `SYSTEM_HEADER_SEARCH_PATHS`, which uses `-isystem`. However, the Xcode generator indiscriminately [passes all paths into the `HEADER_SEARCH_PATHS`](https://gitlab.kitware.com/cmake/cmake/blob/fddd559406558a2037733e5b760e9dd04e9edfd1/Source/cmGlobalXCodeGenerator.cxx#L2048).3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16743VS: Use Windows SDK 10 from a custom folder2018-09-15T09:30:46-04:00Ilia KVS: Use Windows SDK 10 from a custom folderHi!
On my computer I have the latest Windows 10 SDK v10.0.14393.0 which is installed to C:\Program Files (x86)\Windows Kits\10.
I develop the project on few machines, so I created few bundles with dev toolset (msbuild & co) and with ...Hi!
On my computer I have the latest Windows 10 SDK v10.0.14393.0 which is installed to C:\Program Files (x86)\Windows Kits\10.
I develop the project on few machines, so I created few bundles with dev toolset (msbuild & co) and with Windows SDK RTM version 10.0.10240.0.
The problem is that I cannot configure CMake to use Windows 10 SDK from the directory I unpacked it to. It always chooses the latest v10.0.14393.0 installed on my computer.
CMake gets SDK version by `cmGlobalVisualStudio14Generator::GetWindows10SDKVersion` which takes the SDK root directory from the register and then looks up the installed SDK with version `${CMAKE_SYSTEM_VERSION}`, or returns the default (the most recent) version.
I have no trubles with compiler (I just specified the correct path to SDK) but I can't do it for CMake.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16738Visual Studio project type selection and linker preference inconsistency2019-03-07T03:48:47-05:00Christian PfeifferVisual Studio project type selection and linker preference inconsistencyUnder VS, the linker is implicitly defined by the type of project. Now I'm currently working on a library that consists almost exclusively out of Fortran code and only very minor amounts of C/C++ code, making it preferable to use the For...Under VS, the linker is implicitly defined by the type of project. Now I'm currently working on a library that consists almost exclusively out of Fortran code and only very minor amounts of C/C++ code, making it preferable to use the Fortran linker. To that end, we're using separate object libraries for each source files of each language and link them together in a separate target that has some dummy Fortran source files and the aforementioned object files as sources.
Under most generators, it's fine to use the `CMAKE_<LANG>_LINKER_PREFERENCE` variable or `LINKER_LANGUAGE` property to adjust the linker used. However, for Visual Studio, the logic in CMake is to create a `.vfproj` if and only if the only language in the sources (and for object files their source language) is Fortran (see `cmGlobalVisualStudioGenerator::TargetIsFortranOnly` ). Not only does this mean that the linker language selection that is possible in other generators won't work with VS, but during the generation of the link line, the determined linker language is being ignored as far as the `CMAKE_<LANG>_IMPLICIT_LINK_DIRECTORIES` and `CMAKE_<LANG>_IMPLICIT_LINK_LIBRARIES` variables are concerned in `cmComputeLinkInformation::AddImplicitLinkInfo`.
Consequentially, if you configure the linker preferences in a way that Fortran is being chosen over C/C++ as linker language, the link line is generated incorrectly under Visual Studio causing such link processes to fail. I'm not sure what the best approach to address this issue is, whether it's ignoring the user set linker preferences so that under VS generators Fortran will be chosen if and only if there are only Fortran sources or whether the logic of the project generation should be adapted to differentiate between object and normal sources and consider the user provided linker choice if there's only object sources.3.9.0https://gitlab.kitware.com/cmake/cmake/-/issues/16733Add generator expressions for macOS bundle targets2017-04-03T23:02:56-04:00Kevin WojniakAdd generator expressions for macOS bundle targets`TARGET_FILE` currently for macOS bundles goes to the /Contents/MacOS/XXX file, and `TARGET_FILE_DIR` goes to the /Contents/MacOS/ directory. It would be nice if there were generator expressions that mapped to the bundle and bundle paren...`TARGET_FILE` currently for macOS bundles goes to the /Contents/MacOS/XXX file, and `TARGET_FILE_DIR` goes to the /Contents/MacOS/ directory. It would be nice if there were generator expressions that mapped to the bundle and bundle parent directory, for example `TARGET_BUNDLE` and `TARGET_BUNDLE_DIR`. Currently we have to use relative paths, like `$<TARGET_FILE_DIR:${TARGET}>/../../` which is more difficult to read.3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16680When building for iOS with XCode generator, MACOSX_PACKAGE_LOCATION prepends ...2017-05-04T16:23:48-04:00vshashenkoWhen building for iOS with XCode generator, MACOSX_PACKAGE_LOCATION prepends '../' to the path givenMACOSX_PACKAGE_LOCATION property behaves as documented only for macOS. For iOS, however, if the location is set to something other than 'Resources' then it will be prepended with '../' effectively placing the files outside of the bundle....MACOSX_PACKAGE_LOCATION property behaves as documented only for macOS. For iOS, however, if the location is set to something other than 'Resources' then it will be prepended with '../' effectively placing the files outside of the bundle. The 'Resources' value seems to have a special meaning on iOS and the files are actually placed in the bundle root. But if use 'Resources/AnotherFolder', it gets prepended with '../' as well.
I've also found this message in the mailing list describing the same problem: https://cmake.org/pipermail/cmake/2016-August/064125.html3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16678ExternalProject git checkout fails when tag name matches path name2017-05-04T16:23:48-04:00David GlessnerExternalProject git checkout fails when tag name matches path nameExternalProject fails when the GIT_TAG matches a directory name in the repo being checked out. For example:
```
[ 44%] Performing update step for 'aaa'
fatal: ambiguous argument 'bbb': both revision and filename
Use '--' to separate path...ExternalProject fails when the GIT_TAG matches a directory name in the repo being checked out. For example:
```
[ 44%] Performing update step for 'aaa'
fatal: ambiguous argument 'bbb': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Current branch bbb is up to date.
```
The following patch fixed it for me. I didn't look to see if other places needed a `--` separator.
```
--- /usr/share/cmake-3.6/Modules/ExternalProject.cmake 2016-09-07 09:11:58.000000000 -0500
+++ ExternalProject.cmake-3.6 2016-09-23 12:50:09.153230047 -0500
@@ -573,7 +573,7 @@
endif()
execute_process(
- COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag}
+ COMMAND \"${git_EXECUTABLE}\" \${git_options} checkout ${git_tag} --
WORKING_DIRECTORY \"${work_dir}/${src_name}\"
RESULT_VARIABLE error_code
)
```3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16663cmake.m4 CMAKE_FIND_PACKAGE ignores any previously set flags/libs2017-05-04T16:23:48-04:00Johncmake.m4 CMAKE_FIND_PACKAGE ignores any previously set flags/libsWhen calling CMAKE_FIND_PACKAGE from the cmake.m4 file for a given package, the test of the FLAGS and LIBS variable length is non zero (test -n) and then sets the flag/lib variable to the output of the cmake --find-package.
It should ...When calling CMAKE_FIND_PACKAGE from the cmake.m4 file for a given package, the test of the FLAGS and LIBS variable length is non zero (test -n) and then sets the flag/lib variable to the output of the cmake --find-package.
It should be check with the FLAG/LIB vriable is already set to something (test -z) and only setting it to the cmake value IF it is not already set.3.9.0https://gitlab.kitware.com/cmake/cmake/-/issues/16640automoc does not generate moc_predefs.h2018-12-02T16:03:59-05:00Fabian Vogtautomoc does not generate moc_predefs.hWhen building a Qt application on i686, moc causes:
moc_iconapplet_FERWDM656PUOUJ.cpp:128:21: error: 'class IconApplet' has no member named 'open64'; did you mean 'open'?
This is due to moc not defining `_GNUC_` >= 2, so it emits code ...When building a Qt application on i686, moc causes:
moc_iconapplet_FERWDM656PUOUJ.cpp:128:21: error: 'class IconApplet' has no member named 'open64'; did you mean 'open'?
This is due to moc not defining `_GNUC_` >= 2, so it emits code that does not match the header.
This issue is easily reproducable in a i686 build of kget or plasma-workspace.
This bug is fixed in Qt 5.8 as it dumps the list of compiler internal macros into a moc_predefs.h file but CMake does not do that: https://bugreports.qt.io/browse/QTBUG-577963.9.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/16607Process script mode eats 2 first bytes of input2017-05-04T16:23:50-04:00Paweł BylicaProcess script mode eats 2 first bytes of inputWhen process substitution is used in shell, the 2 first bytes are ignored by cmake.
Example:
cmake -P <(echo "cmake_policy(VERSION 3.6)")
will produce following error:
CMake Error at /proc/self/fd/11:1 (ake_policy):
Unk...When process substitution is used in shell, the 2 first bytes are ignored by cmake.
Example:
cmake -P <(echo "cmake_policy(VERSION 3.6)")
will produce following error:
CMake Error at /proc/self/fd/11:1 (ake_policy):
Unknown CMake command "ake_policy".
The workaround is to add 2 spaces at the beginning of the input.3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/16594NUMBER_OF_LOGICAL_CORES does not return what it says it does.2019-02-28T16:08:08-05:00Nicolás BértoloNUMBER_OF_LOGICAL_CORES does not return what it says it does.The documentation suggests that for the cmake_host_system_information() query NUMBER_OF_LOGICAL_CORES is the total number of cores.
Source: https://cmake.org/cmake/help/v3.7/command/cmake_host_system_information.html?highlight=number_of...The documentation suggests that for the cmake_host_system_information() query NUMBER_OF_LOGICAL_CORES is the total number of cores.
Source: https://cmake.org/cmake/help/v3.7/command/cmake_host_system_information.html?highlight=number_of_logical_cores.
But the source code says this:
` unsigned int GetNumberOfLogicalCPU(); // per physical cpu`
Excerpt from Source/kwsys/SystemInformation.hxx.in
It is clear to me that the documentation is wrong.
IMHO, a new variable called TOTAL_NUMBER_OF_CORES should be introduced and NUMBER_OF_LOGICAL_CORES should be renamed to NUMBER_OF_LOGICAL_CORES_PER_PHYSICAL_CORE.3.9.0https://gitlab.kitware.com/cmake/cmake/-/issues/16473Feature request: Exporting symbols from static libraries linked with executab...2020-02-06T13:26:10-05:00Bertrand BellenotFeature request: Exporting symbols from static libraries linked with executable/dllWe (cling/ROOT projects on Windows) would need to export symbols coming not only from object files, but also from static (e.g. system) libraries from our executable, and to do so, we would need to pass one (or more) .def files containing...We (cling/ROOT projects on Windows) would need to export symbols coming not only from object files, but also from static (e.g. system) libraries from our executable, and to do so, we would need to pass one (or more) .def files containing the list of symbols to export. Since the MS linker only support one single .def file, would it be possible for us to specify one (or more) extra .def file in a CMakeLists.txt and let CMake to somehow merge them into the final generated one (exportall.def)?
Something like this:
```
if(MSVC)
set_target_properties(cling PROPERTIES WINDOWS_EXPORT_ALL_SYMBOLS 1)
set_property(TARGET cling APPEND_STRING PROPERTY DEF_FILES " filename1.def filename2.def ... filenameN.def ")
endif(MSVC)
```
And this would somehow merge filename1.def, filename2.def ... filenameN.def into the exportall.def (generated by WINDOWS_EXPORT_ALL_SYMBOLS) and then passed to the linker...
That would be very useful. Thanks in advance!
Cheers, Bertrand.3.9.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/16185WriteCompilerDetectionHeader generates broken static_assert macro for c++982018-09-18T14:18:56-04:00Daniele E. DomenichelliWriteCompilerDetectionHeader generates broken static_assert macro for c++98`write_compiler_detection_header` generates for the `cxx_static_assert` feature and the gcc compiler something like this:
```c++
# if (__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && (__cplusplus >= 201103L || (defined(__GXX_EXPERIMENT...`write_compiler_detection_header` generates for the `cxx_static_assert` feature and the gcc compiler something like this:
```c++
# if (__GNUC__ * 100 + __GNUC_MINOR__) >= 404 && (__cplusplus >= 201103L || (defined(__GXX_EXPERIMENTAL_CXX0X__) && __GXX_EXPERIMENTAL_CXX0X__))
# define FOO_COMPILER_CXX_STATIC_ASSERT 1
# else
# define FOO_COMPILER_CXX_STATIC_ASSERT 0
# endif
```
[...]
```c++
# if FOO_COMPILER_CXX_STATIC_ASSERT
# define FOO_STATIC_ASSERT(X) static_assert(X, #X)
# define FOO_STATIC_ASSERT_MSG(X, MSG) static_assert(X, MSG)
# else
template<bool> struct FOOStaticAssert;
template<> struct FOOStaticAssert<true>{};
# define FOO_STATIC_ASSERT(X) sizeof(FOOStaticAssert<X>)
# define FOO_STATIC_ASSERT_MSG(X, MSG) sizeof(FOOStaticAssert<X>)
# endif
```
This macros, that works everywhere in c++11 will not work everywhere in c++98. For example:
```c++
#include "foo.h"
template <int val>
struct data_structure
{
FOO_STATIC_ASSERT_MSG((val > 0), "val should be greater than 0");
};
int main()
{
#ifndef FAIL_ASSERT
data_structure<42> ds_ok;
#else
data_structure<-5> ds_not_ok;
#endif
}
```
In c++11:
```
$ g++ -std=c++11 -DFAIL_ASSERT=0 -o /tmp/a.out /tmp/foo.cpp # compiles as expected
$ g++ -std=c++11 -DFAIL_ASSERT=1 -o /tmp/a.out /tmp/foo.cpp # fails as expected
/tmp/foo.cpp: In instantiation of ‘struct data_structure<-5>’:
/tmp/foo.cpp:32:24: required from here
/tmp/foo.cpp:10:43: error: static assertion failed: val should be greater than 0
# define FOO_STATIC_ASSERT_MSG(X, MSG) static_assert(X, MSG)
^
/tmp/foo.cpp:23:5: note: in expansion of macro ‘FOO_STATIC_ASSERT_MSG’
FOO_STATIC_ASSERT_MSG((val > 0), "val should be greater than 0");
^
```
In c++98:
```
$ g++ -std=c++98 -DFAIL_ASSERT=0 -o /tmp/a.out /tmp/foo.cpp # fails!!
/tmp/foo.cpp:15:43: error: expected unqualified-id before ‘sizeof’
# define FOO_STATIC_ASSERT_MSG(X, MSG) sizeof(FOOStaticAssert<X>)
^
/tmp/foo.cpp:23:5: note: in expansion of macro ‘FOO_STATIC_ASSERT_MSG’
FOO_STATIC_ASSERT_MSG((val > 0), "val should be greater than 0");
^
```
I don't know if this behaviour is expected, or if I'm doing something wrong but I cannot find documentation about this anywhere. Since this macro generates code that is not portable, I'd rather have it defined empty in c++98.3.9.0Daniel PfeiferDaniel Pfeiferhttps://gitlab.kitware.com/cmake/cmake/-/issues/16103AUTORCC will not regenerate qrc when a resource changes2018-12-07T09:57:12-05:00Kitware RobotAUTORCC will not regenerate qrc when a resource changesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16103). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=16103). Further discussion may take place here.3.9.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/15751cmake Qt moc files' autogen failed with Q_OBJECT in source code comments2018-12-07T09:57:25-05:00Kitware Robotcmake Qt moc files' autogen failed with Q_OBJECT in source code commentsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15751). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15751). Further discussion may take place here.3.9.0Sebastian HoltermannSebastian Holtermannhttps://gitlab.kitware.com/cmake/cmake/-/issues/15441Xcode generator does not generate scheme2017-06-27T15:00:50-04:00Kitware RobotXcode generator does not generate schemeThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15441). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15441). Further discussion may take place here.3.9.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/14460AC_ARG_VARs ignored in CMAKE_FIND_PACKAGE macro in cmake.m42018-12-07T09:58:16-05:00Kitware RobotAC_ARG_VARs ignored in CMAKE_FIND_PACKAGE macro in cmake.m4This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14460). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14460). Further discussion may take place here.3.9.0https://gitlab.kitware.com/cmake/cmake/-/issues/14335CMake does not error on duplicate else()2018-12-07T09:58:21-05:00Kitware RobotCMake does not error on duplicate else()This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14335). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14335). Further discussion may take place here.3.9.0Gregor JasnyGregor Jasny