7 ms·

I'm no longer interested in cmake or any other dynamically typed build specification language (actually an old-fasioned, string-based scripting language in the

by Rochus 4y ago

I'm no longer interested in cmake or any other dynamically typed build specification language (actually an old-fasioned, string-based scripting language in the case of cmake). I tried to like cmake for twenty years. Now I'm migrating all my projects to BUSY. I'm even leaving qmake behind because it essentially suffers from the same disadvantages than cmake. GN is a much superior build system (or meta build system, if you insist), but unfortunately it is also dynamically typed using glorified strings for all kinds of semantically significant stuff. I want to be able to statically check my build specification and profit of 60 years of programming language best practices, not to guess around and waste time with a specification language suitable for toy projects if at all. BUSY is not yet a standard, but it has the potential. There is enough room in the world for different standards on the same topic.

elcritch 4y ago
Oh cmake is full of so many gotchas. Dynamically typed specification languages are so painful. BUSY looks cool! Unfortunately my work projects rely on another big C++ project that has its own meta cmake layer. One thought, it looks like you're quoting a shell string like: ""NAPPGUI_BUILD_DIR=\"" + tostring(root_build_dir) + "\"" That'll break in annoying (possibly insecure) ways and is tedious to write the quotes. Perhaps you could add a 'quotedString' proc? Maybe: ""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir) Speaking of standards, have you tried talking with any cmake collaborators? I recall reading a post on HN discussing a possible new cmake frontend language. Something like BUSY as a frontend could be cool. BTW, here's my latest attempt to avoid dynamic configuration files by making a YAML like in Nim: https://github.com/elcritch/cimporter/blob/exper-interp/tests/rcutils_cimport.nim https://github.com/elcritch/cimporter/blob/exper-interp/test... It may look a bit complicated at first, but the underlying syntax rules are surprisingly simple and consistent. There are only a few small macros for convenience like the 'list' one that replaces array syntax. Best of all that means I get all the goodies of a statically typed language like type annotations from the LSP.
- Rochus 4y ago
  Thanks, I appreciate. > it looks like you're quoting a shell string like: That's not particularly a shell string, but a DEFINE; the rule is to declare them as they are required by the compiler command line of a given platform. I can add a quoted_string() predeclared procedure if it helps. > have you tried talking with any cmake collaborators ... Something like BUSY as a frontend could be cool. No, I haven't; the BUSY spec is open source and available if need be, but for one part I would be very surprised if it was used just as is for the mentioned purpose, and on the other part I'm not sure whether it is a decent approach to add yet another layer to cmake (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, increasing the confusion we already have).
  - elcritch 4y ago
    > That's not particularly a shell string, but a DEFINE Ah I am guessing that you are invoking the compiler using ‘sh’ (or cmd.exe on win). Otherwise you wouldn’t need the extra quotes. But then you should properly quote for the posix shell. Though you could exec the compiler but then you could probably keep it as a list. > I'm not sure whether it is a decent approach to add yet another layer to cmake Yah that’s the problem. Especially with large legacy build systems. > (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, Well I think they meant it’d built on the c++ layer. But it’d still need the old cmake language parser still.
AbusiveHNAdmin 4y ago
[dead]
simplotek 4y ago
> I tried to like cmake for twenty years. This statement alone automatically eliminates any credibility from what you said. CMake was revolutionized with CMake 3.0, which was released in 2014. Since then CMake became a radically different build system, and got so many things right it became the de facto standard. Also, CMake is a build system generator. It's just a high level specification that generates build systems that you pick, like make, ninja, even visual studio and Xcode.
- Rochus 4y ago
  I started to use it when I used VTK in the early 2000; I closely followed all of its lifecycles, including all pipe dreams; and thank you so much for teaching me about build systems.
  - simplotek 4y ago
    > I started to use it when I used VTK in the early 2000; Irrelevant. The whole point is that cmake 3.0, which was released in 2014, is an entirely different beast. See "modern cmake". It makes no sense at all to argue thing about stuff just because you used something two decades ago. Totally irrational.
doodlesdev 4y ago
What about Meson? Apart from CMake it's the build system I've seen the most recently. Personally enjoy it a lot. Popularity of tools at least for me is always a consideration since it means it's easier to get help from other people or assemble a team of contributors to a project.
- bitwize 4y ago
  But it's not statically typed. Good luck building anything bigger than a toy without static typing.
  - doodlesdev 4y ago
    A toy such as... DXVK, elementaryOS, Geary, GTK, almost any GNOME application, GStreamer, i3, libfuse, libcamera, Mesa, MPV, Cisco's OpenH264, PipeWire, PostgreSQL, Qemu, SciPy or systemd? I guess our definitions of what's a toy are different :) Take a look at a list of projects using Meson here: https://mesonbuild.com/Users.html https://mesonbuild.com/Users.html
- Rochus 4y ago
  Meson did indeed some things better than cmake, and I seriously evaluated and considered it for my projects; but on the other hand it's still a dynamic language and has quite some peculiarities, and after analyzing many projects using Meson, where people have used work-arounds against the intent of the language, I decided to come up with my own proposal. Meson also depends on Python which hinders ab initio bootstrap (a major goal of BUSY), and the non-Python versions are not fully compatible or not cross-platform.
  - andai 4y ago
    Not sure if this is the right place to mention this, but the Python keyword activated my neurons: upon running LeanCreator.exe I was greeted with two error boxes: lldb-vscode.exe - System Error: The code execution cannot proceed because python310.dll was not found. lldb.exe - System Error: The code execution cannot proceed because python310.dll was not found. This occurs every time the program is run, though the program does indeed start, although I haven't been able to test it much since I'm not very familiar with Qt and Qt Creator. Edit: I'm trying to create a Hello World. File> New File Or Project only lets me "import" one, so I "imported" an empty folder. Nothing seems to happen in the UI (there is no indication that a project has been created or opened, projects button is greyed out, and I can't find a way to add cpp files), though it did create a bunch of project files in that folder.
johnny22 4y ago
even qt left qmake behind in favor of cmake, so you're not the only one :)
- Rochus 4y ago
  Yes, unfortunately they decided to replace one antiquated technology by yet another one. It's a pity that QtC didn't come up with something much better and just adopted cmake instead.
  - AbusiveHNAdmin 4y ago
    [dead]
  - simplotek 4y ago
    > Yes, unfortunately they decided to replace one antiquated technology by yet another one. Your statement makes no sense and reads like you have an irrational axe to grind regarding cmake. CMake is just a way t provide high level descriptions of your project and from that generate a build system of your choosing. It does its job well and better than any alternative. Making random claims like "outdated" is meaningless, specially as you can use cmake to generate Ninja or visual studio projects.
    - deleted 4y ago
      [deleted]

by Rochus 4y ago

elcritch 4y ago

Oh cmake is full of so many gotchas. Dynamically typed specification languages are so painful. BUSY looks cool! Unfortunately my work projects rely on another big C++ project that has its own meta cmake layer. One thought, it looks like you're quoting a shell string like: ""NAPPGUI_BUILD_DIR=\"" + tostring(root_build_dir) + "\"" That'll break in annoying (possibly insecure) ways and is tedious to write the quotes. Perhaps you could add a 'quotedString' proc? Maybe: ""NAPPGUI_BUILD_DIR=" + quotedStr(root_build_dir) Speaking of standards, have you tried talking with any cmake collaborators? I recall reading a post on HN discussing a possible new cmake frontend language. Something like BUSY as a frontend could be cool. BTW, here's my latest attempt to avoid dynamic configuration files by making a YAML like in Nim: https://github.com/elcritch/cimporter/blob/exper-interp/tests/rcutils_cimport.nim https://github.com/elcritch/cimporter/blob/exper-interp/test... It may look a bit complicated at first, but the underlying syntax rules are surprisingly simple and consistent. There are only a few small macros for convenience like the 'list' one that replaces array syntax. Best of all that means I get all the goodies of a statically typed language like type annotations from the LSP.

Rochus 4y ago
Thanks, I appreciate. > it looks like you're quoting a shell string like: That's not particularly a shell string, but a DEFINE; the rule is to declare them as they are required by the compiler command line of a given platform. I can add a quoted_string() predeclared procedure if it helps. > have you tried talking with any cmake collaborators ... Something like BUSY as a frontend could be cool. No, I haven't; the BUSY spec is open source and available if need be, but for one part I would be very surprised if it was used just as is for the mentioned purpose, and on the other part I'm not sure whether it is a decent approach to add yet another layer to cmake (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, increasing the confusion we already have).
- elcritch 4y ago
  > That's not particularly a shell string, but a DEFINE Ah I am guessing that you are invoking the compiler using ‘sh’ (or cmd.exe on win). Otherwise you wouldn’t need the extra quotes. But then you should properly quote for the posix shell. Though you could exec the compiler but then you could probably keep it as a list. > I'm not sure whether it is a decent approach to add yet another layer to cmake Yah that’s the problem. Especially with large legacy build systems. > (the parser would then likely be written in cmake language and all the legacy would still have to be present for backward compatibility, Well I think they meant it’d built on the c++ layer. But it’d still need the old cmake language parser still.

AbusiveHNAdmin 4y ago

[dead]

simplotek 4y ago

> I tried to like cmake for twenty years. This statement alone automatically eliminates any credibility from what you said. CMake was revolutionized with CMake 3.0, which was released in 2014. Since then CMake became a radically different build system, and got so many things right it became the de facto standard. Also, CMake is a build system generator. It's just a high level specification that generates build systems that you pick, like make, ninja, even visual studio and Xcode.

Rochus 4y ago
I started to use it when I used VTK in the early 2000; I closely followed all of its lifecycles, including all pipe dreams; and thank you so much for teaching me about build systems.
- simplotek 4y ago
  > I started to use it when I used VTK in the early 2000; Irrelevant. The whole point is that cmake 3.0, which was released in 2014, is an entirely different beast. See "modern cmake". It makes no sense at all to argue thing about stuff just because you used something two decades ago. Totally irrational.

doodlesdev 4y ago

What about Meson? Apart from CMake it's the build system I've seen the most recently. Personally enjoy it a lot. Popularity of tools at least for me is always a consideration since it means it's easier to get help from other people or assemble a team of contributors to a project.

bitwize 4y ago
But it's not statically typed. Good luck building anything bigger than a toy without static typing.
- doodlesdev 4y ago
  A toy such as... DXVK, elementaryOS, Geary, GTK, almost any GNOME application, GStreamer, i3, libfuse, libcamera, Mesa, MPV, Cisco's OpenH264, PipeWire, PostgreSQL, Qemu, SciPy or systemd? I guess our definitions of what's a toy are different :) Take a look at a list of projects using Meson here: https://mesonbuild.com/Users.html https://mesonbuild.com/Users.html
Rochus 4y ago
Meson did indeed some things better than cmake, and I seriously evaluated and considered it for my projects; but on the other hand it's still a dynamic language and has quite some peculiarities, and after analyzing many projects using Meson, where people have used work-arounds against the intent of the language, I decided to come up with my own proposal. Meson also depends on Python which hinders ab initio bootstrap (a major goal of BUSY), and the non-Python versions are not fully compatible or not cross-platform.
- andai 4y ago
  Not sure if this is the right place to mention this, but the Python keyword activated my neurons: upon running LeanCreator.exe I was greeted with two error boxes: lldb-vscode.exe - System Error: The code execution cannot proceed because python310.dll was not found. lldb.exe - System Error: The code execution cannot proceed because python310.dll was not found. This occurs every time the program is run, though the program does indeed start, although I haven't been able to test it much since I'm not very familiar with Qt and Qt Creator. Edit: I'm trying to create a Hello World. File> New File Or Project only lets me "import" one, so I "imported" an empty folder. Nothing seems to happen in the UI (there is no indication that a project has been created or opened, projects button is greyed out, and I can't find a way to add cpp files), though it did create a bunch of project files in that folder.

johnny22 4y ago

even qt left qmake behind in favor of cmake, so you're not the only one :)

Rochus 4y ago
Yes, unfortunately they decided to replace one antiquated technology by yet another one. It's a pity that QtC didn't come up with something much better and just adopted cmake instead.
- AbusiveHNAdmin 4y ago
  [dead]
- simplotek 4y ago
  > Yes, unfortunately they decided to replace one antiquated technology by yet another one. Your statement makes no sense and reads like you have an irrational axe to grind regarding cmake. CMake is just a way t provide high level descriptions of your project and from that generate a build system of your choosing. It does its job well and better than any alternative. Making random claims like "outdated" is meaningless, specially as you can use cmake to generate Ninja or visual studio projects.
  - deleted 4y ago
    [deleted]