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.
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.
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.
> 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).
> 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.
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.
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.
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.
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.
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.
The file and project wizzard is on the todo list (see readme); I recommend you download e.g. the LeanQt source and open the top-level BUSY file with LeanCreator to experiment.
Concerning "lldb-vscode.exe": I never saw this and don't know what it means; maybe LeanCreator has found an Clang/Lldb installation somewhere which is compiled with Python support, but Python is not in the path; it's possible that you get this error on start because LeanCreator tries to get information about the toolchains it finds by running the programs; you likely get rid of this error if you put the Python executable in the PATH before starting LeanCreator.
So I indeed got the same error when running lldb, so I upgraded my llvm from 14 to 15*. This did not solve the error, so I installed Python 3.10 and put it on the path. Now launching LeanCreator takes 26 seconds (nothing appears to happen, so I thought it was broken, but after a long time the window appears) but there are no error boxes anymore.
Edit: followed your suggestion.
01:59:38: Running steps for project LeanQt...
Error while building/deploying project LeanQt (kit: Desktop)
When executing step "Busy Build"
Oops, that's not a good trade-off; does it always take that long when you start LeanCreator on your machine, or was it - as I would expect - only the first time it required to locate the debugger? If it repeats with each start I should add an option to disable this search or reduce the timeout. Can you try whether it also takes that long if you directly start lldb on the command line?
Ok, I see, but apparently LeanCreator hangs when accessing your toolchain and consequently also cannot use it to build anything; either there is an installation issue with the toolchain or an incompatibility with LeanCreator which I don't know yet. The 30 secs are probably the timeout in LeanCreator when trying to run an executable of the toolchain. Which version of Clang/lldb have you installed? Have you also MSVC or MingW installed on your machine?
Maybe there is compatibility issue with lldb; I already found an issue with the recent lldb version on Mac M1 (see https://github.com/rochus-keller/LeanCreator/issues/1). You could try to tempoarily rename the clang/lldb directory so LeanCreator doesn't see it anymore at startup.
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 :)
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.
> 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.
