CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-02-21T21:58:26-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25705ci: Add sonarcloud annotation links2024-02-21T21:58:26-05:00Ben Boeckelci: Add sonarcloud annotation linksThe following discussion from !9267 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9267#note_1484439): (+2 comments)
> Do we know the URL where results will b...The following discussion from !9267 should be addressed:
- [ ] @ben.boeckel started a [discussion](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9267#note_1484439): (+2 comments)
> Do we know the URL where results will be available based on the commit metadata (e.g., the commit hash)? If we do, the robot could craft a URL to add to pipelines with the job (I think there are some missing connections to actually do it, but it could serve as incentive to complete them).
We can craft the link based on the reason the pipeline is running.
Cc: @ryan.krattiger1https://gitlab.kitware.com/cmake/cmake/-/issues/25689SonarCloud Analysis2024-02-28T11:06:22-05:00William SciaroniSonarCloud AnalysisSonarSource has gained a reputation for being a market leader in the Static Analysis space. I believe that CMake would benefit from having an additional static analysis tool running during development. This focus on continuous improvemen...SonarSource has gained a reputation for being a market leader in the Static Analysis space. I believe that CMake would benefit from having an additional static analysis tool running during development. This focus on continuous improvement and clean-as-you-code mentality will improve the CMake project with time.
SonarSource's SonarCloud product is free for OpenSource projects. Therefore, I would like to see CMake incorporate SonarCloud analysis as part of the CI pipeline.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/25467Why separate Windows (CRLF) and Linux (LF) sources needed in https://cmake.or...2023-12-06T16:38:29-05:00gitartpianoWhy separate Windows (CRLF) and Linux (LF) sources needed in https://cmake.org/download/ ? Could we just have LF only?Assuming that every editor and tool chain supports the Unix line ending (LF only) of the source files why Windows edition of the source package is needed at https://cmake.org/download/? It does not solve any problems, but adds to the con...Assuming that every editor and tool chain supports the Unix line ending (LF only) of the source files why Windows edition of the source package is needed at https://cmake.org/download/? It does not solve any problems, but adds to the confusion.
If the above assumption is wrong please provide the reason, I (maybe other software developers too) would really like to learn why every other open source package can get away with a single type of source release, but not `cmake`.https://gitlab.kitware.com/cmake/cmake/-/issues/25387Please provide fully statically linked binaries of CMake2023-11-03T08:03:01-04:00John DoePlease provide fully statically linked binaries of CMakeAs per [this Discourse thread](https://discourse.cmake.org/t/please-provide-fully-statically-linked-binaries-of-cmake/9299) I'm opening an issue here.
The [CMake binaries for linux](https://github.com/Kitware/CMake/releases/download/v3....As per [this Discourse thread](https://discourse.cmake.org/t/please-provide-fully-statically-linked-binaries-of-cmake/9299) I'm opening an issue here.
The [CMake binaries for linux](https://github.com/Kitware/CMake/releases/download/v3.27.7/cmake-3.27.7-linux-x86_64.tar.gz) provided on the website have no dependencies except on GLIBC, which is linked dynamically...
Is it possible to instead provide linux binaries that are **fully statically linked** to [MUSL](https://musl.libc.org)? Such binaries will work out of the box on both GLIBC and MUSL distros, and also work on distros with a GLIBC that is too old/new.
The `cmake-gui` binary is the only exception, because it has other dependencies (Qt), however Qt can be built on MUSL and linked statically. Void Linux (musl version) offers working copies of Qt5 and Qt6, with patches:
[void-packages/tree/master/srcpkgs/qt5](https://github.com/void-linux/void-packages/tree/master/srcpkgs/qt5)
[void-packages/tree/master/srcpkgs/qt6-base](https://github.com/void-linux/void-packages/tree/master/srcpkgs/qt6-base)
Full list of qt5-\* and qt6-\* packages provided by Void are searchable on [this page](https://voidlinux.org/packages/?arch=x86_64-musl&q=qt5).https://gitlab.kitware.com/cmake/cmake/-/issues/25339Add CMakePresets for CMake itself2023-10-17T04:09:59-04:00Cristian LeAdd CMakePresets for CMake itselfShould include some basic presets for CMake itself. Not sure how practical it would be on the CI right now, but at least for (new) developers it would be useful to provide some basic ones:
- `default`
- `debug`
- `docs` (although it woul...Should include some basic presets for CMake itself. Not sure how practical it would be on the CI right now, but at least for (new) developers it would be useful to provide some basic ones:
- `default`
- `debug`
- `docs` (although it would make more sense to have it be buildable with plain `python`?)
- `gui`
- `cpack`
- `ctest`
Any other useful presets to implement or make them known?https://gitlab.kitware.com/cmake/cmake/-/issues/24374bootstrap/iOS: CMake Error while checking type size2023-01-30T11:50:08-05:00Torrekie Genbootstrap/iOS: CMake Error while checking type sizeAttempting to bootstrap cmake on iOS 14.5.1 with root access (jailbroken), all size check failed like this:
```
-- Performing Curl Test HAVE_FSETXATTR_6 - Success
-- Check size of sa_family_t
CMake Error at Modules/CheckTypeSize.cmake:14...Attempting to bootstrap cmake on iOS 14.5.1 with root access (jailbroken), all size check failed like this:
```
-- Performing Curl Test HAVE_FSETXATTR_6 - Success
-- Check size of sa_family_t
CMake Error at Modules/CheckTypeSize.cmake:148 (try_compile):
Cannot copy output executable
''
to destination specified by COPY_FILE:
'/buildroot/cmake-3.25.2/CMakeFiles/CheckTypeSize/SIZEOF_SA_FAMILY_T.bin'
Recorded try_compile output location doesn't exist:
/buildroot/cmake-3.25.2/CMakeFiles/CMakeScratch/TryCompile-vWOvyt/cmTC_23101
Call Stack (most recent call first):
Modules/CheckTypeSize.cmake:278 (__check_type_size_impl)
Utilities/cmcurl/CMakeLists.txt:1271 (check_type_size)
```
Using LLVM 14 Clang
```
iPad:/buildroot/cmake-3.25.2 root# $CC -v
clang version 14.0.0 (https://github.com/apple/llvm-project 3dade082a9b1989207a7fa7f3975868485d16a49)
Target: arm64-apple-ios13.0
Thread model: posix
InstalledDir: /usr/lib/llvm-14/bin
```
I have already checked other similar issues but didn't find a proper solution for that
Steps to reproduce:
1. get source tarbal and change working directory
2. `./bootstrap --prefix=/usr --no-system-libs --datadir=/share/cmake --parallel=4 --docdir=/share/doc/cmake --mandir=/share/man --system-zlib --system-bzip2 -- -DCMake_INSTALL_BASH_COMP_DIR=/usr/share/bash-completion/completions -DCMake_BUILD_LTO=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_SYSTEM_NAME=Darwin -DCMAKE_SYSTEM_PROCESSOR=aarch64 -DCMAKE_INSTALL_SYSCONFDIR=/etc`https://gitlab.kitware.com/cmake/cmake/-/issues/24280CMake 3.25.1 Fails to Bootstrap on old openSUSE Linux2023-01-11T17:40:18-05:00Martin VahiCMake 3.25.1 Fails to Bootstrap on old openSUSE LinuxBootstrapping is something that should work also on old machines,
specially for a project like a build system that aims to be
a fancy GNU Make replacement. The build steps:
```
./bootstrap --prefix=/home/mmmv/applications/CMake/v_3_25_...Bootstrapping is something that should work also on old machines,
specially for a project like a build system that aims to be
a fancy GNU Make replacement. The build steps:
```
./bootstrap --prefix=/home/mmmv/applications/CMake/v_3_25_1 --no-qt-gui
# That step worked fine. No errors what so ever.
```
```
gmake
# step gave the following symptoms:
```
The symptoms:
```
[ 23%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/vssh/libssh2.c.o
[ 23%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/vssh/wolfssh.c.o
[ 23%] Linking C static library libcmcurl.a
[ 23%] Built target cmcurl
[ 23%] Building C object Utilities/cmcurl/CMakeFiles/curltest.dir/curltest.c.o
[ 23%] Linking C executable curltest
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(sha256.c.o): in function `my_sha256_init':
sha256.c:(.text+0x45): undefined reference to `EVP_MD_CTX_new'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(sha256.c.o): in function `Curl_sha256it':
sha256.c:(.text+0x94): undefined reference to `EVP_MD_CTX_new'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: sha256.c:(.text+0xdd): undefined reference to `EVP_MD_CTX_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(sha256.c.o): in function `my_sha256_final':
sha256.c:(.text+0x36): undefined reference to `EVP_MD_CTX_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_sha256sum':
openssl.c:(.text+0x17b): undefined reference to `EVP_MD_CTX_new'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x1bc): undefined reference to `EVP_MD_CTX_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_version':
openssl.c:(.text+0x733): undefined reference to `OpenSSL_version'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_init':
openssl.c:(.text+0xf6c): undefined reference to `OPENSSL_init_ssl'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `cert_stuff':
openssl.c:(.text+0x2243): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x26a9): undefined reference to `EVP_PKEY_get_id'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x2da6): undefined reference to `OPENSSL_sk_pop'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x2de3): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x2e0a): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_connect_step1':
openssl.c:(.text+0x31de): undefined reference to `TLS_client_method'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3546): undefined reference to `SSL_CTX_set_options'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x380d): undefined reference to `SSL_CTX_set_ciphersuites'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x38d0): undefined reference to `SSL_CTX_set_post_handshake_auth'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3a48): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3a5c): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3abb): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3b12): undefined reference to `SSL_CTX_load_verify_file'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3b3c): undefined reference to `SSL_CTX_load_verify_dir'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3c6f): undefined reference to `SSL_CTX_set_keylog_callback'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4109): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `Curl_ossl_certchain':
openssl.c:(.text+0x418a): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4209): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x42d0): undefined reference to `X509_get_version'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4427): undefined reference to `X509_get_X509_PUBKEY'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x449b): undefined reference to `X509_get0_extensions'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x44a7): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x44fb): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x450c): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4581): undefined reference to `X509_get0_notBefore'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x45d1): undefined reference to `X509_get0_notAfter'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4635): undefined reference to `EVP_PKEY_get_id'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4770): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4782): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4922): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4934): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4946): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o):openssl.c:(.text+0x4958): more undefined references to `EVP_PKEY_get_bn_param' follow
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `Curl_ossl_verifyhost':
openssl.c:(.text+0x4ea7): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4ef2): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4f0e): undefined reference to `ASN1_STRING_get0_data'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x523c): undefined reference to `ASN1_STRING_get0_data'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `servercert':
openssl.c:(.text+0x52ec): undefined reference to `SSL_get1_peer_certificate'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x53f7): undefined reference to `X509_get0_notBefore'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5446): undefined reference to `X509_get0_notAfter'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x55e9): undefined reference to `X509_get_X509_PUBKEY'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5627): undefined reference to `X509_get_X509_PUBKEY'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5d79): undefined reference to `SSL_get1_peer_certificate'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5d99): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5dc0): undefined reference to `OPENSSL_sk_num'
collect2: error: ld returned 1 exit status
Utilities/cmcurl/CMakeFiles/curltest.dir/build.make:101: recipe for target 'Utilities/cmcurl/curltest' failed
gmake[2]: *** [Utilities/cmcurl/curltest] Error 1
CMakeFiles/Makefile2:1873: recipe for target 'Utilities/cmcurl/CMakeFiles/curltest.dir/all' failed
gmake[1]: *** [Utilities/cmcurl/CMakeFiles/curltest.dir/all] Error 2
Makefile:165: recipe for target 'all' failed
gmake: *** [all] Error 2
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ uname -a
Linux terminal01 4.4.126-48-default #1 SMP Sat Apr 7 05:22:50 UTC 2018 (f24992c) x86_64 x86_64 x86_64 GNU/Linux
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ gcc -version
gcc: error: unrecognized command line option ‘-version’
gcc: fatal error: no input files
compilation terminated.
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux)
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ ls
Auxiliary CMakeGraphVizOptions.cmake CompileFlags.cmake Templates
Bootstrap.cmk CMakeLists.txt Copyright.txt Testing
CMake.DeveloperReference.HTML.qs CMakeLogo.gif DartConfig.cmake Tests
CMake.Dialogs.QtGUI.qs CONTRIBUTING.rst DartConfiguration.tcl Utilities
CMake.Documentation.SphinxHTML.qs CPackConfig.cmake Help bin
CMake.qs CPackSourceConfig.cmake Licenses bootstrap
CMakeCPack.cmake CTestConfig.cmake Makefile cmake_install.cmake
CMakeCPackOptions.cmake CTestCustom.cmake Modules cmake_uninstall.cmake
CMakeCPackOptions.cmake.in CTestCustom.cmake.in Packaging cmake_uninstall.cmake.in
CMakeCache.txt CTestScript.cmake README.rst configure
CMakeFiles CTestTestfile.cmake Source doxygen.config
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$
```https://gitlab.kitware.com/cmake/cmake/-/issues/24276bootstrap cmake in infinite loop on CentOS5-32bit2023-01-11T18:41:42-05:00Axel K. Reinholdbootstrap cmake in infinite loop on CentOS5-32biti need a fairly new cmake on an old CentOS-5-32bit installation.
bootstrap cmake-3.22.6 compiles fine with gcc 9.3.0 and last CentOS5-glibc:
```
Name : glibc Relocations: (not relocatable)
Version ...i need a fairly new cmake on an old CentOS-5-32bit installation.
bootstrap cmake-3.22.6 compiles fine with gcc 9.3.0 and last CentOS5-glibc:
```
Name : glibc Relocations: (not relocatable)
Version : 2.5 Vendor: CentOS
Release : 123.el5_11.3 Build Date: Mon 17 Aug 2015 06:32:38 PM CEST
```
bootstrapped cmake can not build cmake - it goes into endless loop
trace ends with:
```
cmake-3.22.6/Modules/CMakeDetermineCompilerId.cmake(828):
file(STRINGS cmake-3.22.6/CMakeFiles/3.22.6/CompilerIdC/a.out
CMAKE_C_COMPILER_ID_STRINGS LIMIT_COUNT 38 REGEX .?I.?N.?F.?O.?:.?[A-Za-z0-9_]+\[[^]]*\] )
```
i tracked down the loop the while-loop in cmFileCommand.cxx does never terminate:
```c++
// Parse strings out of the file.
int output_size = 0;
std::vector<std::string> strings;
std::string s;
while ((!limit_count || strings.size() < limit_count) &&
(limit_input < 0 || static_cast<int>(fin.tellg()) < limit_input) &&
fin) {
```
... never ends
can you help or is 32-bit no more possible?https://gitlab.kitware.com/cmake/cmake/-/issues/23977Build CMake using PCH to speed up build2022-09-19T17:50:19-04:00Rick BudéBuild CMake using PCH to speed up buildIt seems that Precompiled Headers (PCH) are not being used in any of the CMakeLists from CMake, and I was wondering whether this was a deliberate choice.
Enabling PCH seems like a very easy way to speed up the build of CMake itself.
To...It seems that Precompiled Headers (PCH) are not being used in any of the CMakeLists from CMake, and I was wondering whether this was a deliberate choice.
Enabling PCH seems like a very easy way to speed up the build of CMake itself.
To test this out, I added in `Source/CMakeLists.txt`:
```cmake
#Toggle precompiled headers on/off
option(enable-pch "Speed up the building of CMake with precompiled headers" OFF)
if(enable-pch)
#List of common STL headers (<string>,<memory>,etc), only for C++ with generator expressions
set(PCH_LIST
"$<$<COMPILE_LANGUAGE:CXX>:<string$<ANGLE-R>>"
"$<$<COMPILE_LANGUAGE:CXX>:<functional$<ANGLE-R>>"
"$<$<COMPILE_LANGUAGE:CXX>:<memory$<ANGLE-R>>"
"$<$<COMPILE_LANGUAGE:CXX>:<fstream$<ANGLE-R>>"
"$<$<COMPILE_LANGUAGE:CXX>:<istream$<ANGLE-R>>"
"$<$<COMPILE_LANGUAGE:CXX>:<set$<ANGLE-R>>"
"$<$<COMPILE_LANGUAGE:CXX>:<chrono$<ANGLE-R>>"
)
#Precompile headers for a few targets with many sources
target_precompile_headers(CMakeLib PRIVATE ${PCH_LIST})
target_precompile_headers(CTestLib PRIVATE ${PCH_LIST})
target_precompile_headers(CPackLib PRIVATE ${PCH_LIST})
endif()
```
As you can see, I only added PCH for a few "large" targets. I didn't bother messing with the REUSE_FROM keyword (and any problems that might give).
The performance impact is not earth-shattering, but still a decent 20-30%:
```
#with PCH:
cmake .. -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -Denable-pch=1
time ninja -j24
real 0m15.153s
user 4m16.579s
sys 0m27.343s
#without PCH:
cmake .. -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -Denable-pch=0
time ninja -j24
real 0m19.265s
user 5m58.963s
sys 0m31.163s
```
I have not tested other compilers, nor have I tried to optimize the list of headers by analyzing a profiler output.
This might also benefit #23787.https://gitlab.kitware.com/cmake/cmake/-/issues/23912Create a custom clang-tidy plugin2024-01-29T15:21:23-05:00Kyle EdwardsCreate a custom clang-tidy pluginWe have a number of C++ conventions specific to the CMake code base that would be nice to automatically enforce. clang-tidy allows you to write your own custom plugin:
https://clang.llvm.org/extra/clang-tidy/Contributing.html
The purpo...We have a number of C++ conventions specific to the CMake code base that would be nice to automatically enforce. clang-tidy allows you to write your own custom plugin:
https://clang.llvm.org/extra/clang-tidy/Contributing.html
The purpose of this issue is to track the progress in writing this plugin.https://gitlab.kitware.com/cmake/cmake/-/issues/23787Investigate build times of CMake2022-09-19T11:56:16-04:00friendlyanonInvestigate build times of CMakeI have seen people bringing up the build times of CMake as a pain point and I have also noticed that during my contributions, however for me it's an infrequent occurence, so I don't mind all that much.
I think source based distribution...I have seen people bringing up the build times of CMake as a pain point and I have also noticed that during my contributions, however for me it's an infrequent occurence, so I don't mind all that much.
I think source based distributions are affected for one here.
I have compiled CMake via the bootstrap script on an Ubuntu VM with 2 cores, CMake being at commit ad2e7f3c537dc88ea8140bab67c43d25695637f1 with the following command:
```
CPP=clang-cpp-12 \
LD=ld.lld-12 \
CC=clang-12 \
CXX=clang++-12 \
CFLAGS="-ftime-trace -isystem /usr/include/c++/10 -isystem /usr/include/x86_64-linux-gnu/c++/10" \
CXXFLAGS="-ftime-trace -isystem /usr/include/c++/10 -isystem /usr/include/x86_64-linux-gnu/c++/10 -stdlib=libstdc++" \
LDFLAGS="-L/usr/lib/gcc/x86_64-linux-gnu/10" \
time sh -ec '.../cmake/bootstrap --system-libs --bootstrap-system-libuv --bootstrap-system-jsoncpp --bootstrap-system-librhash --generator=Ninja --parallel=2 -- -DBUILD_TESTING=0 && ninja'
```
`time` output:
```
1473.50user 70.72system 13:19.68elapsed 193%CPU (0avgtext+0avgdata 357652maxresident)k
273376inputs+745440outputs (7633major+14968114minor)pagefaults 0swaps
```
Analysis of the traces:
<details>
<summary>ClangBuildAnalyzer output</summary>
```
Analyzing build trace from '.../out'...
**** Time summary:
Compilation (1330 times):
Parsing (frontend): 1425.5 s
Codegen & opts (backend): 675.2 s
**** Files that took longest to parse (compiler frontend):
9339 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGeneratorTarget.cxx.o
7424 ms: .../Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o
7164 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalNinjaGenerator.cxx.o
6971 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalGenerator.cxx.o
6872 ms: .../Source/CMakeFiles/CMakeLib.dir/cmQtAutoGenInitializer.cxx.o
6680 ms: .../Source/CMakeFiles/CTestLib.dir/CTest/cmCTestTestHandler.cxx.o
6380 ms: .../Source/CMakeFiles/CMakeLib.dir/cmLocalGenerator.cxx.o
6324 ms: .../Source/CMakeFiles/CMakeLib.dir/cmMakefileTargetGenerator.cxx.o
6290 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGeneratorExpressionNode.cxx.o
6157 ms: .../Source/CMakeFiles/CMakeLib.dir/cmFileCommand.cxx.o
**** Files that took longest to codegen (compiler backend):
32903 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGeneratorTarget.cxx.o
15247 ms: .../Source/CMakeFiles/CMakeLib.dir/cmLocalGenerator.cxx.o
14481 ms: .../Source/CMakeFiles/CMakeLib.dir/cmMakefile.cxx.o
13265 ms: .../Source/CMakeFiles/CMakeLib.dir/cmake.cxx.o
12786 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalNinjaGenerator.cxx.o
12148 ms: .../Source/CMakeFiles/CTestLib.dir/CTest/cmCTestTestHandler.cxx.o
11985 ms: .../Source/CMakeFiles/CMakeLib.dir/cmGlobalGenerator.cxx.o
11581 ms: .../Source/CMakeFiles/CTestLib.dir/cmCTest.cxx.o
11339 ms: .../Source/CMakeFiles/CMakeLib.dir/cmTarget.cxx.o
11086 ms: .../Source/CMakeFiles/CTestLib.dir/CTest/cmCTestCoverageHandler.cxx.o
**** Templates that took longest to instantiate:
8396 ms: std::_Rb_tree<std::basic_string<char>, std::pair<const std::basic_st... (682 times, avg 12 ms)
6939 ms: std::unique_ptr<cmTargetInternals> (360 times, avg 19 ms)
6884 ms: std::set<std::basic_string<char>>::insert (211 times, avg 32 ms)
6827 ms: std::unique_ptr<cmCustomCommand> (341 times, avg 20 ms)
6679 ms: std::make_shared<cmListFileFunction::Implementation, std::basic_stri... (414 times, avg 16 ms)
6524 ms: std::_Rb_tree<std::basic_string<char>, std::pair<const std::basic_st... (341 times, avg 19 ms)
6521 ms: std::unique_ptr<cmMakefile::DeferCommands> (338 times, avg 19 ms)
6331 ms: std::unordered_map<int, int> (353 times, avg 17 ms)
5611 ms: std::allocate_shared<cmListFileFunction::Implementation, std::alloca... (414 times, avg 13 ms)
5601 ms: std::__uniq_ptr_data<cmTargetInternals, std::default_delete<cmTarget... (360 times, avg 15 ms)
5539 ms: std::__uniq_ptr_impl<cmTargetInternals, std::default_delete<cmTarget... (360 times, avg 15 ms)
5537 ms: std::__uniq_ptr_data<cmCustomCommand, std::default_delete<cmCustomCo... (341 times, avg 16 ms)
5487 ms: std::__uniq_ptr_impl<cmCustomCommand, std::default_delete<cmCustomCo... (341 times, avg 16 ms)
5422 ms: std::shared_ptr<cmListFileFunction::Implementation>::shared_ptr<std:... (414 times, avg 13 ms)
5254 ms: std::__shared_ptr<cmListFileFunction::Implementation, __gnu_cxx::_S_... (414 times, avg 12 ms)
5254 ms: std::__uniq_ptr_data<cmMakefile::DeferCommands, std::default_delete<... (338 times, avg 15 ms)
5187 ms: std::basic_string<char16_t>::_M_construct<const char16_t *> (1300 times, avg 3 ms)
5178 ms: std::basic_string<char32_t>::_M_construct<const char32_t *> (1300 times, avg 3 ms)
5178 ms: std::__uniq_ptr_impl<cmMakefile::DeferCommands, std::default_delete<... (338 times, avg 15 ms)
5007 ms: std::unordered_map<std::basic_string<char>, std::vector<cmSourceFile... (338 times, avg 14 ms)
4930 ms: std::_Hashtable<int, std::pair<const int, int>, std::allocator<std::... (353 times, avg 13 ms)
4898 ms: std::__shared_count<__gnu_cxx::_S_atomic>::__shared_count<cmListFile... (414 times, avg 11 ms)
4736 ms: std::unordered_map<std::basic_string<char>, cmTarget> (338 times, avg 14 ms)
4702 ms: __gnu_cxx::__to_xstring<std::basic_string<wchar_t>, wchar_t> (650 times, avg 7 ms)
4638 ms: std::basic_string<wchar_t>::_M_construct<wchar_t *> (1300 times, avg 3 ms)
4637 ms: std::unique_ptr<cmSourceGroupInternals> (205 times, avg 22 ms)
4537 ms: std::unique_ptr<cmCustomCommand>::~unique_ptr (338 times, avg 13 ms)
4533 ms: std::_Rb_tree<std::basic_string<char>, std::basic_string<char>, std:... (176 times, avg 25 ms)
4516 ms: std::unordered_map<std::basic_string<char>, cmTarget *> (357 times, avg 12 ms)
4463 ms: std::_Hashtable<std::basic_string<char>, std::pair<const std::basic_... (338 times, avg 13 ms)
**** Template sets that took longest to instantiate:
71362 ms: std::unique_ptr<$> (3545 times, avg 20 ms)
69927 ms: std::__and_<$> (44084 times, avg 1 ms)
57320 ms: std::__uniq_ptr_data<$> (3545 times, avg 16 ms)
56637 ms: std::__uniq_ptr_impl<$> (3545 times, avg 15 ms)
50846 ms: std::_Hashtable<$> (4722 times, avg 10 ms)
48097 ms: std::unordered_map<$> (3430 times, avg 14 ms)
43853 ms: std::vector<$> (13551 times, avg 3 ms)
40290 ms: std::map<$> (6183 times, avg 6 ms)
31260 ms: std::optional<$> (2275 times, avg 13 ms)
28617 ms: std::tuple<$> (3779 times, avg 7 ms)
27139 ms: std::__or_<$> (20659 times, avg 1 ms)
25785 ms: std::_Rb_tree<$> (7729 times, avg 3 ms)
23284 ms: std::_Vector_base<$> (13340 times, avg 1 ms)
22182 ms: std::pair<$> (6727 times, avg 3 ms)
20258 ms: std::__detail::_Hashtable_alloc<$> (4129 times, avg 4 ms)
17808 ms: std::is_convertible<$> (13898 times, avg 1 ms)
17115 ms: std::allocator<$> (14786 times, avg 1 ms)
12374 ms: std::is_move_constructible<$> (6027 times, avg 2 ms)
12314 ms: std::_Optional_base<$> (2275 times, avg 5 ms)
12174 ms: std::basic_string<$> (2600 times, avg 4 ms)
11933 ms: std::__detail::_Hash_node<$> (3490 times, avg 3 ms)
11797 ms: std::__detail::_Hash_node_value_base<$> (3466 times, avg 3 ms)
11497 ms: __gnu_cxx::__aligned_buffer<$> (3459 times, avg 3 ms)
11230 ms: std::_TupleConstraints<$>::__is_implicitly_constructible<$> (6863 times, avg 1 ms)
10898 ms: std::basic_string<$>::_M_construct<$> (3877 times, avg 2 ms)
10218 ms: std::basic_string<$>::basic_string (4022 times, avg 2 ms)
10053 ms: std::basic_string<$>::_M_construct_aux<$> (3759 times, avg 2 ms)
10022 ms: std::chrono::duration<$> (6040 times, avg 1 ms)
9742 ms: std::set<$>::insert (317 times, avg 30 ms)
8944 ms: std::vector<$>::~vector (2570 times, avg 3 ms)
**** Functions that took longest to compile:
2593 ms: cmCTestCoverageHandler::HandleGCovCoverage(cmCTestCoverageHandlerCon... (.../Source/CTest/cmCTestCoverageHandler.cxx)
2551 ms: (anonymous namespace)::HandleTargetsMode(std::vector<std::__cxx11::b... (.../Source/cmInstallCommand.cxx)
2304 ms: cmMakefileTargetGenerator::WriteObjectRuleFiles(cmSourceFile const&) (.../Source/cmMakefileTargetGenerator.cxx)
2153 ms: cmNinjaNormalTargetGenerator::WriteLinkStatement(std::__cxx11::basic... (.../Source/cmNinjaNormalTargetGenerator.cxx)
1907 ms: cmTarget::cmTarget(std::__cxx11::basic_string<char, std::char_traits... (.../Source/cmTarget.cxx)
1657 ms: (anonymous namespace)::Target::Dump() (.../Source/cmFileAPICodemodel.cxx)
1641 ms: cmCTestCoverageHandler::HandleLCovCoverage(cmCTestCoverageHandlerCon... (.../Source/CTest/cmCTestCoverageHandler.cxx)
1627 ms: main (.../Source/CPack/cpack.cxx)
1423 ms: cmake::SetArgs(std::vector<std::__cxx11::basic_string<char, std::cha... (.../Source/cmake.cxx)
1410 ms: cmcmd::ExecuteCMakeCommand(std::vector<std::__cxx11::basic_string<ch... (.../Source/cmcmd.cxx)
1384 ms: cmCPackNSISGenerator::PackageFiles() (.../Source/CPack/cmCPackNSISGenerator.cxx)
1352 ms: cmCoreTryCompile::TryCompileCode(std::vector<std::__cxx11::basic_str... (.../Source/cmCoreTryCompile.cxx)
1271 ms: cmNinjaTargetGenerator::WriteObjectBuildStatement(cmSourceFile const... (.../Source/cmNinjaTargetGenerator.cxx)
1262 ms: cmFindPackageCommand::InitialPass(std::vector<std::__cxx11::basic_st... (.../Source/cmFindPackageCommand.cxx)
1228 ms: (anonymous namespace)::HandleTransformCommand(std::vector<std::__cxx... (.../Source/cmListCommand.cxx)
1186 ms: cmCTestCoverageHandler::ProcessHandler() (.../Source/CTest/cmCTestCoverageHandler.cxx)
1134 ms: cmFindPackageCommand::SearchPrefix(std::__cxx11::basic_string<char, ... (.../Source/cmFindPackageCommand.cxx)
1102 ms: cmMakefileLibraryTargetGenerator::WriteLibraryRules(std::__cxx11::ba... (.../Source/cmMakefileLibraryTargetGenerator.cxx)
1056 ms: cmNinjaTargetGenerator::WriteCompileRule(std::__cxx11::basic_string<... (.../Source/cmNinjaTargetGenerator.cxx)
1029 ms: (anonymous namespace)::cmQtAutoMocUicT::InitFromInfo(cmQtAutoGenerat... (.../Source/cmQtAutoMocUic.cxx)
990 ms: cmCTestSubmitHandler::SubmitUsingHTTP(std::__cxx11::basic_string<cha... (.../Source/CTest/cmCTestSubmitHandler.cxx)
982 ms: cmQtAutoGenInitializer::InitAutogenTarget() (.../Source/cmQtAutoGenInitializer.cxx)
978 ms: cmCMakeLanguageCommand(std::vector<cmListFileArgument, std::allocato... (.../Source/cmCMakeLanguageCommand.cxx)
907 ms: (anonymous namespace)::HandleDownloadCommand(std::vector<std::__cxx1... (.../Source/cmFileCommand.cxx)
893 ms: cmCTestMemCheckHandler::InitializeMemoryChecking() (.../Source/CTest/cmCTestMemCheckHandler.cxx)
847 ms: cmQtAutoGenInitializer::InitScanFiles() (.../Source/cmQtAutoGenInitializer.cxx)
845 ms: cmCPackGenerator::InstallCMakeProject(bool, std::__cxx11::basic_stri... (.../Source/CPack/cmCPackGenerator.cxx)
831 ms: cmCTestSubmitHandler::HandleCDashUploadFile(std::__cxx11::basic_stri... (.../Source/CTest/cmCTestSubmitHandler.cxx)
806 ms: cmCPackGenerator::DoPackage() (.../Source/CPack/cmCPackGenerator.cxx)
804 ms: cmGlobalGenerator::EnableLanguage(std::vector<std::__cxx11::basic_st... (.../Source/cmGlobalGenerator.cxx)
**** Function sets that took longest to compile / optimize:
5057 ms: void std::vector<$>::_M_range_insert<$>(__gnu_cxx::__normal_iterator... (78 times, avg 64 ms)
4243 ms: std::_Rb_tree<$>::_M_get_insert_hint_unique_pos(std::_Rb_tree_const_... (179 times, avg 23 ms)
4238 ms: void std::vector<$>::_M_realloc_insert<$>(__gnu_cxx::__normal_iterat... (137 times, avg 30 ms)
4053 ms: std::_Rb_tree<$>::_M_get_insert_unique_pos(std::__cxx11::basic_strin... (247 times, avg 16 ms)
3110 ms: std::_Rb_tree<$>::_M_erase(std::_Rb_tree_node<$>*) (469 times, avg 6 ms)
3091 ms: std::_Rb_tree_iterator<$> std::_Rb_tree<$>::_M_emplace_hint_unique<$... (201 times, avg 15 ms)
2563 ms: (anonymous namespace)::HandleTargetsMode(std::vector<$> const&, cmEx... (2 times, avg 1281 ms)
2537 ms: void std::vector<$>::_M_realloc_insert<$>(__gnu_cxx::__normal_iterat... (88 times, avg 28 ms)
2169 ms: cmNinjaNormalTargetGenerator::WriteLinkStatement(std::__cxx11::basic... (2 times, avg 1084 ms)
1950 ms: std::_Function_handler<$>::_M_manager(std::_Any_data&, std::_Any_dat... (424 times, avg 4 ms)
1934 ms: std::vector<$>::~vector() (733 times, avg 2 ms)
1925 ms: std::__cxx11::basic_string<$>* std::__uninitialized_copy<$>::__unini... (113 times, avg 17 ms)
1911 ms: cmTarget::cmTarget(std::__cxx11::basic_string<$> const&, cmStateEnum... (2 times, avg 955 ms)
1548 ms: __gnu_cxx::__normal_iterator<$> std::__find_if<$>(__gnu_cxx::__norma... (83 times, avg 18 ms)
1435 ms: cmcmd::ExecuteCMakeCommand(std::vector<$> const&, std::unique_ptr<$>) (2 times, avg 717 ms)
1429 ms: cmake::SetArgs(std::vector<$> const&) (2 times, avg 714 ms)
1373 ms: cmCoreTryCompile::TryCompileCode(std::vector<$> const&, bool) (2 times, avg 686 ms)
1305 ms: void std::_Rb_tree<$>::_M_construct_node<$>(std::_Rb_tree_node<$>*, ... (192 times, avg 6 ms)
1277 ms: cmNinjaTargetGenerator::WriteObjectBuildStatement(cmSourceFile const... (2 times, avg 638 ms)
1269 ms: cmFindPackageCommand::InitialPass(std::vector<$> const&) (2 times, avg 634 ms)
1238 ms: (anonymous namespace)::HandleTransformCommand(std::vector<$> const&,... (2 times, avg 619 ms)
1135 ms: cmFindPackageCommand::SearchPrefix(std::__cxx11::basic_string<$> con... (2 times, avg 567 ms)
1133 ms: void std::__merge_sort_with_buffer<$>(std::reverse_iterator<$>, std:... (2 times, avg 566 ms)
1114 ms: cmMakefileLibraryTargetGenerator::WriteLibraryRules(std::__cxx11::ba... (2 times, avg 557 ms)
1102 ms: void cmComputeLinkDepends::AddLinkEntries<$>(int, std::vector<$> con... (4 times, avg 275 ms)
1082 ms: cmNinjaTargetGenerator::WriteCompileRule(std::__cxx11::basic_string<... (2 times, avg 541 ms)
1055 ms: std::_Hashtable<$>::_M_insert_unique_node(std::__cxx11::basic_string... (53 times, avg 19 ms)
1047 ms: std::vector<std::__cxx11::basic_string<char, std::char_traits<char>,... (39 times, avg 26 ms)
1009 ms: void std::__insertion_sort<$>(__gnu_cxx::__normal_iterator<$>, __gnu... (28 times, avg 36 ms)
996 ms: cmCTestSubmitHandler::SubmitUsingHTTP(std::__cxx11::basic_string<$> ... (2 times, avg 498 ms)
*** Expensive headers:
199497 ms: .../Source/cmMakefile.h (included 338 times, avg 590 ms), included via:
cmMakefile.cxx.o (2095 ms)
cmSetCommand.cxx.o (1769 ms)
cmSetDirectoryPropertiesCommand.cxx.o (1729 ms)
cmGetTestPropertyCommand.cxx.o (1653 ms)
cmAddDependenciesCommand.cxx.o (1643 ms)
cmIncludeGuardCommand.cxx.o (1629 ms)
...
195757 ms: /usr/include/c++/10/string (included 650 times, avg 301 ms), included via:
cmParseCoberturaCoverage.cxx.o cmParseCoberturaCoverage.h (658 ms)
cmSetPropertyCommand.cxx.o cmSetPropertyCommand.h (624 ms)
cmSetTargetPropertiesCommand.cxx.o cmSetTargetPropertiesCommand.h (611 ms)
cmSubdirDependsCommand.cxx.o cmSubdirDependsCommand.h (610 ms)
cmFileLockPool.cxx.o cmFileLockPool.h (598 ms)
cmCTestBuildCommand.cxx.o cmCTestBuildCommand.h (594 ms)
...
94589 ms: .../Source/cmListFileCache.h (included 413 times, avg 229 ms), included via:
cmListFileCache.cxx.o (1234 ms)
cmComputeComponentGraph.cxx.o cmComputeComponentGraph.h cmGraphAdjacencyList.h (1094 ms)
cmMessenger.cxx.o cmMessenger.h (876 ms)
cmGeneratorExpressionDAGChecker.cxx.o cmGeneratorExpressionDAGChecker.h (852 ms)
cmTest.cxx.o cmTest.h (819 ms)
cmFunctionBlocker.cxx.o cmFunctionBlocker.h (805 ms)
...
93187 ms: .../Source/cmSystemTools.h (included 503 times, avg 185 ms), included via:
cmSystemTools.cxx.o (1145 ms)
cmHexFileConverter.cxx.o (898 ms)
cmWorkingDirectory.cxx.o (811 ms)
cmFileLockUnix.cxx (760 ms)
bindexplib.cxx.o (615 ms)
cmLoadCommandCommand.cxx.o cmListFileCache.h (588 ms)
...
88748 ms: /usr/include/c++/10/functional (included 548 times, avg 161 ms), included via:
cmDependsCompiler.cxx.o cmDependsCompiler.h (735 ms)
cmDefinitions.cxx.o cmDefinitions.h (690 ms)
cmCMakePresetsGraphReadJSONTestPresets.cxx.o (653 ms)
cmCustomCommandGenerator.cxx.o cmCustomCommandGenerator.h (634 ms)
cmCMakePresetsGraphReadJSONBuildPresets.cxx.o (628 ms)
cmCMakePresetsGraphReadJSONConfigurePresets.cxx.o (622 ms)
...
86814 ms: .../Source/cmGlobalGenerator.h (included 149 times, avg 582 ms), included via:
cmGlobalGenerator.cxx.o (2357 ms)
cmSourceFileLocation.cxx.o (1677 ms)
cmTargetPropCommandBase.cxx.o (1664 ms)
cmBuildCommand.cxx.o (1642 ms)
cmInstallTargetsCommand.cxx.o (1598 ms)
cmGetDirectoryPropertyCommand.cxx.o (1589 ms)
...
80512 ms: .../Source/cmake.h (included 119 times, avg 676 ms), included via:
cmake.cxx.o (2722 ms)
cmWhileCommand.cxx.o (1419 ms)
cmVariableWatchCommand.cxx.o (1238 ms)
cmFileSet.cxx.o (1216 ms)
cmGeneratorExpressionDAGChecker.cxx.o (1209 ms)
cmIfCommand.cxx.o (1205 ms)
...
66818 ms: /usr/include/c++/10/memory (included 560 times, avg 119 ms), included via:
cmBinUtilsWindowsPELinker.cxx.o cmBinUtilsWindowsPELinker.h (560 ms)
cmCommandArgumentParserHelper.cxx.o cmCommandArgumentParserHelper.h (504 ms)
cmSourceFile.cxx.o cmSourceFile.h (497 ms)
cmCTestSubmitCommand.cxx.o cmCTestSubmitCommand.h (495 ms)
cmQtAutoGen.cxx.o cmQtAutoGen.h (468 ms)
cmFileTimes.cxx.o cmFileTimes.h (463 ms)
...
65322 ms: .../Source/cmAlgorithms.h (included 376 times, avg 173 ms), included via:
cmTarget.cxx.o cmTarget.h (749 ms)
cmNinjaLinkLineComputer.cxx.o cmNinjaLinkLineComputer.h cmLinkLineComputer.h cmStateDirectory.h (743 ms)
cmMSVC60LinkLineComputer.cxx.o cmMSVC60LinkLineComputer.h cmLinkLineComputer.h cmStateDirectory.h (687 ms)
cmLinkLineComputer.cxx.o cmLinkLineComputer.h cmStateDirectory.h (662 ms)
cmOSXBundleGenerator.cxx.o cmGeneratorTarget.h (655 ms)
cmGlobalWatcomWMakeGenerator.cxx.o cmGlobalWatcomWMakeGenerator.h cmGlobalUnixMakefileGenerator3.h cmGeneratorTarget.h (634 ms)
...
65092 ms: /usr/include/c++/10/istream (included 522 times, avg 124 ms), included via:
cmCTestBuildAndTestHandler.cxx.o cmCTestBuildAndTestHandler.h sstream (723 ms)
cmStringAlgorithms.cxx.o cmStringAlgorithms.h sstream (642 ms)
cmQtAutoGenerator.cxx.o cmQtAutoGenerator.h (590 ms)
cmCPackNuGetGenerator.cxx.o cmCPackNuGetGenerator.h cmCPackGenerator.h sstream (540 ms)
cmCPackGenerator.cxx.o cmCPackGenerator.h sstream (499 ms)
cmCTest.cxx.o cmCTest.h sstream (402 ms)
...
done in 0.8s.
```
</details>
It's worth noting that CMake is bootstrapped with PCH support, so that might be a low hanging fruit to look into.https://gitlab.kitware.com/cmake/cmake/-/issues/23649Discuss the best approach to implementing support for additional version schemes2024-02-01T18:59:32-05:00Timothy BrackettDiscuss the best approach to implementing support for additional version schemes# Summary
There have been a number of proposals to expand versioning in CMake.
I like the summary and rationale from #16716.
# Required changes
* Commands
* `cmake_minimum_required`
* `cmake_policy`
* `find_package`
* `PACKA...# Summary
There have been a number of proposals to expand versioning in CMake.
I like the summary and rationale from #16716.
# Required changes
* Commands
* `cmake_minimum_required`
* `cmake_policy`
* `find_package`
* `PACKAGE_FIND_VERSION{,_MAJOR,_MINOR,_PATCH,_TWEAK}`
* `write_basic_package_version_file` `COMPATIBILITY` argument and associated `BasicConfigVersion-<VERSION_SCHEME>.cmake.in` files
* `if`
* `VERSION_{LESS,GREATER,EQUAL,LESS_EQUAL,GREATER_EQUAL}`
* *proposed* `VERSION_MATCHES` or `<VERSION_SCHEME>_MATCHES`
* `project`
* Sets `PROJECT_VERSION{,_MAJOR,_MINOR,_PATCH,_TWEAK}` and `<PROJECT-NAME>_VERSION{,_MAJOR,_MINOR,_PATCH,_TWEAK}`
* *proposed* `PROJECT_VERSION_SCHEME` and `<PROJECT-NAME>_VERSION_SCHEME`
* Additional scheme-specific named version components (e.g `PROJECT_VERSION_PRERELEASE` and `PROJECT_VERSION_BUILD_IDENTIFIER` for semantic version, or `PROJECT_VERSION_LOCAL` for PEP440)?
* Generator expressions
* `VERSION_{LESS,GREATER,EQUAL,LESS_EQUAL,GREATER_EQUAL}`
* *proposed* `VERSION_MATCHES` or `<VERSION_SCHEME>_MATCHES`
`cmake_minimum_required` and `cmake_policy` only require a change if CMake is going to use an expanded version scheme. The stated preference appears to be to ignore prerelease versions, which is the current behavior.
## New comparison operator
`VERSION_SATISFIES` or `VERSION_MATCHES` such that the operation evaluates to `TRUE` if the first argument matches the version spec in the second argument. The version spec can be a single version that the first argument must be compatible with or a set of constraints as in [PEP440 version specifiers](https://peps.python.org/pep-0440/#version-specifiers).
There are a couple of ways that this may be done:
### `MATCHES`/`SATISFIES` operator for each scheme
```cmake
if(<string|expression> <VERSION_SCHEME>_MATCHES <string|expression>)
# Ex
if(1.2.0 SEMVER_MATCHES 1.1.0)
if(1.2.0 PEP440_MATCHES "~=1.1.0 !=1.1.1")
```
This is the approach that I took in !7387.
### Optional scheme argument for `MATCHES`/`SATISFIES`
If this is feasible, it would make the documentation look a little better. Right now, all of the version comparison operations have essentially identical descriptions (of how CMake's current version precedence system works).
If `[VERSION_SCHEME]` is omitted, default to the current behavior (dotted decimal, compare components in order to find a diff, ignore any non-digit, non-. characters and quit immediately if one is found). Allow users to explicitly choose this scheme by specifying `SIMPLE` as the scheme?
#### Infix
```cmake
if(<string|expression> VERSION_MATCHES [VERSION_SCHEME] <string|expression>)
# Ex
if(1.2.0 VERSION_MATCHES SEMVER 1.1.0)
if(1.2.0 VERSION_MATCHES PEP440 "~=1.1.0 !=1.1.1")
```
#### Postfix
```cmake
if(<string|expression> VERSION_MATCHES <string|expression> [VERSION_SCHEME])
# Ex
if(1.2.0 VERSION_MATCHES 1.1.0 SEMVER)
if(1.2.0 VERSION_MATCHES "~=1.1.0 !=1.1.1" PEP440)
```
## Generator expressions
Again, there a couple ways this might be approached:
### New generator expressions for every versioning scheme
```cmake
$<<SCHEME>_MATCHES:v1,v2>
# Ex
$<VERSION_MATCHES:1.2.0,1.1.0>
$<SEMVER_MATCHES:1.2.0,1.1.0>
$<PEP440_MATCHES:1.2.0,"~=1.1.0 !=1.1.1">
```
### Optional third-argument
```cmake
$<VERSION_MATCHES:v1,v2[,SCHEME]>
# Ex
$<VERSION_MATCHES:1.2.0,1.1.0>
$<VERSION_MATCHES:1.2.0,1.1.0,SIMPLE>
$<VERSION_MATCHES:1.2.0,1.1.0,SEMVER>
$<VERSION_MATCHES:1.2.0,"~=1.1.0 !=1.1.1",PEP440)
```
# Links to other issues
Previous work (closed, but with an encouraging comment by @brad.king to re-open when the author has time): !985
Would require something like #22584 / !7386 as a prerequisite.
One partial implementation for semantic version is !7387, but as pointed out there, it might not be the ideal solution to the problem.
Also related to #16656 and #16716.https://gitlab.kitware.com/cmake/cmake/-/issues/22529Enable sccache for debug builds of CMake in gitlab CI2022-10-26T09:41:46-04:00alcroitoEnable sccache for debug builds of CMake in gitlab CII noticed that CMake's gitlab CI does not use sccache for RelWithDebInfo and Debug builds of CMake on Windows
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.1/.gitlab/os-windows.yml#L30
It's possible to enable sccache on those conf...I noticed that CMake's gitlab CI does not use sccache for RelWithDebInfo and Debug builds of CMake on Windows
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.1/.gitlab/os-windows.yml#L30
It's possible to enable sccache on those configs if you replace the `/Zi` flag with `/Z7`.
It has the downside of keeping the debug info in the object files, but for CI purposes it should be ok.
Thought i'd mention if you think it's worthwhile to enable it.
We do that in Qt's CI with our own custom function that replaces the `/Zi` flag in `CMAKE_C/CXX_COMPILER` in the top-
level directory scope.
https://github.com/qt/qtbase/blob/81411cb3a82b97fa80e4ba66b94797abe8d6ef7e/cmake/QtFlagHandlingHelpers.cmake#L951
@ben.boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/22042Document build instructions for CMake itself2021-04-08T07:04:34-04:00Ben BoeckelDocument build instructions for CMake itselfIt seems that we don't have prose documentation for how to build CMake itself beyond the basics. We should probably document cache variables and required packages (in the abstract and concretely for common platforms).
For inspiration, V...It seems that we don't have prose documentation for how to build CMake itself beyond the basics. We should probably document cache variables and required packages (in the abstract and concretely for common platforms).
For inspiration, VTK's [`build.md`](https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/build.md) might be useful.
Cc: @craig.scott @brad.kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21628Utilities/Release: Consolidate Linux docker specs2020-12-22T14:56:34-05:00Brad KingUtilities/Release: Consolidate Linux docker specs!5538 adds `Utilities/Release/linux/aarch64` by largely copying from `Utilities/Release/linux/x86_64` and making some modifications. There are important differences, but ideally we should find a way to avoid duplication and parameterize...!5538 adds `Utilities/Release/linux/aarch64` by largely copying from `Utilities/Release/linux/x86_64` and making some modifications. There are important differences, but ideally we should find a way to avoid duplication and parameterize the specifications.https://gitlab.kitware.com/cmake/cmake/-/issues/21460Unable to install cmake 3.19 on ubuntu 20.04 using the official repo2024-01-29T15:21:42-05:00cor3ntinUnable to install cmake 3.19 on ubuntu 20.04 using the official repoOn Ubuntu 20.04 (focal), the following command fails
```
apt-add-repository 'deb https://apt.kitware.com/ubuntu/ focal main'
apt-get update && apt-get install cmake
```
with
`cmake : Depends: cmake-data (= 3.18.4-0kitware1ubuntu20.04.1...On Ubuntu 20.04 (focal), the following command fails
```
apt-add-repository 'deb https://apt.kitware.com/ubuntu/ focal main'
apt-get update && apt-get install cmake
```
with
`cmake : Depends: cmake-data (= 3.18.4-0kitware1ubuntu20.04.1) but 3.19.0-0kitware1ubuntu20.04.1 is to be installed`https://gitlab.kitware.com/cmake/cmake/-/issues/21412Port `--warn-unused` to `-Wdev` mechanisms2020-11-10T16:25:06-05:00Ben BoeckelPort `--warn-unused` to `-Wdev` mechanisms[This Discourse thread](https://discourse.cmake.org/t/fail-cmake-if-there-are-unused-variables-defined/840) brings up that `--warn-unused` flags are not affected by `-Werror=dev` flags. These should be integrated together.[This Discourse thread](https://discourse.cmake.org/t/fail-cmake-if-there-are-unused-variables-defined/840) brings up that `--warn-unused` flags are not affected by `-Werror=dev` flags. These should be integrated together.https://gitlab.kitware.com/cmake/cmake/-/issues/20733Tests: ExternalProjectUpdate test slow on Visual Studio2021-01-27T09:00:55-05:00Brad KingTests: ExternalProjectUpdate test slow on Visual StudioThe `ExternalProjectUpdate` test takes a very long time to run in VS. Most of the time is spent in the enable language step of each inner build. We can update `Tests/ExternalProjectUpdate/gitrepo.tgz` (and `Tests/ExternalProject/gitrepo...The `ExternalProjectUpdate` test takes a very long time to run in VS. Most of the time is spent in the enable language step of each inner build. We can update `Tests/ExternalProjectUpdate/gitrepo.tgz` (and `Tests/ExternalProject/gitrepo.tgz`) to have a project that just uses custom commands instead of building code. That will make these tests run much faster.https://gitlab.kitware.com/cmake/cmake/-/issues/19889CMakeSL - proposal of a new scripting language for CMake2023-09-01T02:54:24-04:00strykuCMakeSL - proposal of a new scripting language for CMake# Proposal about using CMakeSL (CMake Scripting Language) as an alternative CMake's scripting language.
Hello, I've been working on an alternative scripting language for CMake and I'd like to propose merging it into the CMake codebase.
...# Proposal about using CMakeSL (CMake Scripting Language) as an alternative CMake's scripting language.
Hello, I've been working on an alternative scripting language for CMake and I'd like to propose merging it into the CMake codebase.
Table of Contents
=================
* [Proposal about using CMakeSL (CMake Scripting Language) as an alternative CMake's scripting language.](#proposal-about-using-cmakesl-cmake-scripting-language-as-an-alternative-cmakes-scripting-language)
* [Purpose of this proposal](#purpose-of-this-proposal)
* [Quick links](#quick-links)
* [tl;dr list of pros and cons of the language](#tldr-list-of-pros-and-cons-of-the-language)
* [Pros](#pros)
* [Cons](#cons)
* [Integration with CMake codebase](#integration-with-cmake-codebase)
* [CMakeSL](#cmakesl)
* [Current state of CMakeSL](#current-state-of-cmakesl)
* [Hello world](#hello-world)
* [High-level design](#high-level-design)
* [C++ish style](#cish-style)
* [Mixing CMakeSL with 'old' CMake scripts](#mixing-cmakesl-with-old-cmake-scripts)
* [Tools](#tools)
* [Tests](#tests)
* [Why not use any of the ready made languages](#why-not-use-any-of-the-ready-made-languages)
* [Work to be done before the eventual merge](#work-to-be-done-before-the-eventual-merge)
* [Summary](#summary)
* [Thanks](#thanks)
# Purpose of this proposal
My goal is to present the approach that I took with all its pros and cons, and explain why I think it's a good way for the future of CMake.
The thing that I'd not want to spend too much time on is CMakeSL's API. In this proposal and in CMakeSL's documentation you'll find code like `cmake::minimum_required(cmake::version(3, 14, 4));` where the `cmake::` seems to be a boilerplate, the code looks verbose etc. I want to explicitly point out that it's only an API and, if there will be a need, it can be very easily changed.
# Quick links
* CMakeSL repo: [https://github.com/stryku/cmakesl](https://github.com/stryku/cmakesl)
* Language user guide: [https://github.com/stryku/cmakesl/blob/master/doc/UserGuide.md](https://github.com/stryku/cmakesl/blob/master/doc/UserGuide.md)
* Builtin stuff documentation files: [https://github.com/stryku/cmakesl/tree/master/examples](https://github.com/stryku/cmakesl/tree/master/examples). Documentation is generated from them, using Doxygen.
* Example usage of CMakeSL and its tools: [https://github.com/stryku/cmakesl/tree/master/examples](https://github.com/stryku/cmakesl/tree/master/examples) (for more information about the tools, see [the tools section in README](https://github.com/stryku/cmakesl#tools))
# tl;dr list of pros and cons of the language
## Pros
* Easy to pick up by people with C/C++ (and similar) background.
* C++ tools like clang-format and Doxygen work out-of-the-box.
* Easy to divide into smaller files.
* Can be mixed with 'old' CMake scripts (at `add_subdirectory()` level), which eases migration process.
* Features like classes, namespaces, modularity, type safety and more, which help to work with huge projects.
* It's easy to write tools that provide semantic information: indexer and syntax completion, which help IDE creators.
## Cons
* Probably not the easiest way to write simple things. That, actually, depends on what API CMakeSL would eventually have.
* C++ish syntax can be verbose.
# Integration with CMake codebase
Here's a high-level diagram of CMakeSL and how it's integrated with CMake codebase.
![CMakeSL](/uploads/e913593f143f0cb8fc7bb49fd5e9eda8/CMakeSL.png)
CMakeSL bases on CMake 3.14 (that was the latest version when I started working on it). You can find forked repo here: [https://github.com/stryku/cmake_for_cmakesl](https://github.com/stryku/cmake_for_cmakesl). All required changes are on `cmakesl` branch. A good starting point to check out is the [cmCMakeFacade](https://github.com/stryku/cmake_for_cmakesl/blob/cmakesl/Source/CMakeFacade.hpp) class. That's the interface between CMakeSL and complex CMake systems.
# CMakeSL
CMakeSL is basically a set of libraries that implement a statically typed scripting language. The scripting language is (using some integration code) used by CMake to execute `CMakeLists.cmsl` scripts. The libraries are statically linked to the `cmake` binary, so the result is a regular `cmake` binary with 'old' CMake and CMakeSL support. In [the script](https://github.com/stryku/cmakesl/blob/master/scripts/build_cmake.sh) you can find how to build CMake with CMakeSL support.
It is implemented in C++17 and a little of python3.
## Current state of CMakeSL
CMakeSL is advanced enough to build itself (without generating documentation). See `CMakeLists.cmsl` files in the repo.
## Hello world
```cpp
int main()
{
cmake::minimum_required(cmake::version(3, 14, 3));
auto hello_world = cmake::project("Hello world");
auto sources = { "main.cpp" };
hello_world.add_executable("hw_exec", sources);
return 0;
}
```
## High-level design
The only thing that CMakeSL is supposed to change in a CMake User's life is how they write CMake scripts. CMakeSL is a scripting language and the scripting language only. All well known CMake's concepts like targets, modules, exporting etc. are supposed to be preserved. You can think of CMakeSL as a thin layer, an API to complex CMake systems.
The only stage of CMake usage that CMakeSL affects is the configuration step. The generation step, all the already supported generators, building and other CMake features remain the same.
## C++ish style
You hate it or you love it. I know that a lot of people don't like it and I know that a lot of people complain about imperative paradigm. CMakeSL is highly inspired by C++. It looks and works a lot like C++. It provides well known concepts like types (including builtin generics, e.g. `list<T>`), variables, references, functions, classes with members and methods, namespaces and more. Here's why:
* A lot of C/C++ project uses CMake - If user comes from C/C++ or similar background, it'll be very easy to they to pick up the CMakeSL language, read and maintain its code. Additionally, it's easier to switch between C/C++ and CMakeSL files/tasks.
* In C/C++ projects it's almost certain that there is integrated code formatter and other tools that works with C/C++ language. Thanks to the fact that CMakeSL looks almost exactly like subset of C++, all C/C++ tools, that don't require semantic information, work with CMakeSL files as well. An example can be the CMakeSL repository itself. All `*.cmsl` files there are formatted using `clang-format`, with a style got from the `.clang-format` file - the very same file that is used to format C++ code in the repository. Another example can be CMakeSL's builtin stuff documentation. All its files are under `doc/builtin` directory. There are files that document all the builtin types and namespaces. The documentation is generated using Doxygen. Doxygen also works with regular CMakeSL files.
The whole CMakeSL machinery seems to be an overkill for such a simple task as writing a couple of scripts that instruct CMake how to build a project. Well, that's partially right. It seems complex and unnecessary if you think about the hello world example or a one-executable project. But, CMakeSL aims to make doing simple tasks simple, that's for sure. Furthermore, it provides features like functions, classes, namespaces, modularity, type safety and more, which make it powerful enough to be clear and elegant in huge projects, with thousands of lines of CMakeSL code.
## Mixing CMakeSL with 'old' CMake scripts
CMakeSL scripts can be mixed with 'old' CMake scripts at a directory level. You can NOT mix them in one file or even `include()` 'old' CMake module in a CMakeSL script.
On the other hand, in a CMakeSL script you CAN call `add_subdirectory()` with a `CMakeLists.txt` written in 'old' CMake. In the CMakeSL repo you can see an example of such. In the root `CMakeLists.cmsl` file, there is [an add_subdirectory call](https://github.com/stryku/cmakesl/blob/master/CMakeLists.cmsl#L41) that adds `external/googletest` subdirectory. Of course the `googletest` library doesn't provie CMakeSL scripts. It provides 'old' `CMakeLists.txt`. The `gtest` and `gmock` libraries created there are later on used in tests, in `CMakeLists.cmsl` scripts. Such behavior mitigates eventual migration of a given project, form 'old' CMake to CMakeSL. You don't need to migrate the whole project at once. You migrate a directory after directory, which eases the process.
It works the other way as well. In 'old' `CMakeLists.txt` you can call `add_subdirectory()` with a script implemented in CMakeSL.
## Tools
While C/C++ tools that don't require semantic information (e.g. clang-format, Doxygen) work out-of-the-box, tools like clang code completion can not be used just like that. Because of that, CMakeSL brings two tools that provide CMakeSL's code semantic information. Indexer and code completion. They are implemented in `cmsl_tools` library. It has C language interface, so it can be used practically everywhere. See [the tools section in README](https://github.com/stryku/cmakesl#tools) for more info.
## Tests
Every CMakeSL library has automated tests. They are run on CI. Additionally, Clang's `AddressSanitizer`, `LeakSanitizer` and `UndefinedBehaviorSanitizer` don't complain (they are not integrated on CI yet).
# Why not use any of the ready made languages
That's a very good question that I heard a lot. I agree that using an already existing language would be and option, but I think that it'd be an option in the short term. Look, CMake has been here for almost 20 years. It has a great community. It's been used by huge projects and companies. More projects are migrating to CMake, e.g. Qt. In short, it seems that CMake is going to be used for a long, long time. Which is great, of course, but when you're in a perspective of a couple of decades of project maintaining, you want to keep as many parts of the project as possible in your garden. I believe creating and maintaining scripting language will pay-off in the long term. That's why I designed and wrote CMakeSL without a big list of dependencies and requirements. It's relatively easy to embed CMakeSL into the existing CMake codebase.
# Work to be done before the eventual merge
* The most basic one is the coding style. CMakeSL has different from the rest of CMake. It would need to be aligned.
* Refactor of the integration code. The code at the `cmake_for_cmakesl/cmakesl` branch.
* Review of the CMakeSL code. I've been implementing it basically on my own, without a second pair of reviewing eyes. I believe there is a lot of room for improvement.
* Rewrite Doxygen docs to Sphinx.
* C++17 is required, so CI would need to be updated.
* Test compilation on more architectures and compilers.
# Summary
I think CMakeSL, thanks to its features and compatibility with a lot of C/C++ tools, would be a step in the right direction of CMake life.
I'm open for discussion about any aspect of the project and I'm very curious what do you think about all this.
# Thanks
I'd like to thank to Bartosz Duszel, Piotr Płaza, Stanisław Kubiak and Wojciech Stróżyński for help with this proposal (: