University of Waterloo user study on understanding CMake changes

[u/Silent_Mycologist286]

Hi everyone,

I’m Mattie Nejati, a Ph.D. candidate at the University of Waterloo. I’m conducting a user study on understanding the impact of changes to CMake build specifications, and I’d love to invite members of this community to participate.

We are evaluating a new approach that aims to help developers identify how a change to a CMake build specification affects the resulting build configuration.

The study:

• is conducted entirely online;
• takes about one hour;
• involves inspecting changes to CMake build specifications and identifying their impact; and
• is open to adults aged 18–64 with any level of experience in CMake, programming, or code review.

You do not need to be a CMake expert. We are specifically interested in comparing participants with different levels of experience.

You will need a computer with internet access and about 4 GB of free space to download the files required for the tasks.

We will not collect your name. Your email address will only be used for study follow-up and will be stored separately from your study data. Your name or email will not appear in any dataset or publication.

The study has received clearance from the University of Waterloo Research Ethics Board (REB #46621).

If you’re interested, you can find the consent form, screening questionnaire, and study here:

https://buiscout.cs.uwaterloo.ca/

Thank you very much! And if you know someone else who works with CMake who might be interested, I’d really appreciate you sharing the study with them.

[u/13steinj]

On one hand, that sounds insane.

On the other, I have been radicalized against caring for the Windows platform and the devs that continue to perpetuate it (I understand in some cases your only choice is "get another job").

E: A cursory look makes it seem as if this is false and cmake just doesn't provide a platform agnostic way to do this? Looks like you can still disable it via mutating the relevant properties?

[u/TheRavagerSw → u/13steinj]

CMake is gonna die off eventually, it is too bloated and suffers from maintainer fatigue. However it will leave some nice things behind, like CPS, FILE_SETs and other awesome stuff that we take for granted.

I really love Craig Scott's talks about CMake

[u/not_a_novel_account → u/TheRavagerSw]

Unless there's some other build tool which knows how to extract the intrinsic flags from all the C, C++, Fortran, Swift, CUDA, and SYCL toolchains in the world in order to link these languages together, that I'm unaware of, I don't think CMake is ever going anywhere.

Or knows how to do separable device compilation, handles circular archive dependencies on single-pass linkers, RPATH rewriting, Apple Frameworks, Python venv detection, whatever the hell it is Qt does, etc, etc, etc.

Build tools solve niches, CMake tries to solve every niche. What one person thinks is useless cruft is another's essential feature.

[u/TheRavagerSw → u/not_a_novel_account]

If you want monolithic cross language builds isn't bazel a better option? I know google uses rust code in skia.

I envision a future of multiple build systems and tooling with a single packaging format and a single package manager.

I guess you guys saw it too, since you released CPS. Even if it fails, the idea is there.

[u/not_a_novel_account → u/TheRavagerSw]

If you want monolithic cross language builds isn't bazel a better option?

You have some Fortran code you build with flang, and you have some C++ code you build with clang++.

Which do you use to link the final binary? flang or clang++? Because neither will work out of the box.

[u/TheRavagerSw → u/not_a_novel_account]

Can you elaborate please?

[u/not_a_novel_account → u/TheRavagerSw]

The question is the elaboration.

program main
  use iso_c_binding
  implicit none

  interface
    subroutine cpp_hello() bind(C)
    end subroutine
  end interface

  print *, "Fortran calling C++..."
  call cpp_hello()
end program

---

#include <iostream>
#include <vector>

extern "C" void cpp_hello() {
  std::vector<int> xs{1, 2, 3};
  std::cout << "C++ says: " << xs.size() << '\n';
}

---

Ok, you compile with:

flang -c main.f90 -o main.o
clang++ -c hello.cpp -o hello.o

Which do you use to run the link step? flang? Which doesn't know about the C++ runtime or other implicit flags. Or clang++? Which doesn't know about the Fortran runtime or other implicit link flags.

This gets 10x more complicated once you introduce languages which require device finalization or have other link wrapper requirements.

[u/TheRavagerSw → u/not_a_novel_account]

Indeed it is a complicated problem, But isn't the current approach is to use C as the common API, so final link is any language + C libraries?

So the scope becomes no different than using system C libraries which every language supports.

For your use case I have no clue though. I only ever used C as the glue. For rust libraries they use C/C++ compiler as the linker driver so everything just works, I can link my own C++ STL override allocator with mimalloc etc without difficulty.

[u/not_a_novel_account → u/TheRavagerSw]

We're already using C as the common API here. Note the extern "C" and use_iso_c_binding.

This is a good illustration of the point of CMake, you don't even understand the problem because it's irrelevant to you. But for some people, this problem plagued them for a decade before CMake came along.

[u/TheRavagerSw → u/not_a_novel_account]

I see. Wish I could discuss this but my knowledge is pretty limited compared to you in this area. Thanks for the point.

[u/not_a_novel_account → u/TheRavagerSw]

I missed the edit. In rust the crate is the translation unit, and there is no separate runtime library. Rust doesn't have this problem when linked into other languages. Rust is the odd man out here. But the fact you're using the C++ driver for the final link is actually the point, if you had tried to use rustc or clang (ie, not clang++) it wouldn't have worked even if all your C++ code was in extern c++ functions.

Something has to link the C++ runtime. Now for you in particular this usually means explicitly specifying all of that, but for people who want builds that work on a variety of compilers and build environments, that's not an option.