5 ms·

Why? I do that in CMake. God awful ugly abomination of a language, but it does the work, and is almost universally supported.

chombier 4y ago
Same story here: complex build scripts in CMake, horrible language but at least it has some form(s) of user-defined abstraction. Tried to look into Meson, bumped into this issue, and decided against it for the same reason. I kinda get the rationale that no abstraction primitive should drive common patterns into the standard Meson distribution (an approach which has problems too, but at least it makes sense to me). However, seeing function definitions rejected on the basis of Turing-completeness raised serious doubts about the project at the time, and things haven't changed much on this front apparently[1] [1]: https://mesonbuild.com/Syntax.html#userdefined-functions-and-methods https://mesonbuild.com/Syntax.html#userdefined-functions-and...
- germandiago 4y ago
  I am not sure what stops you from using a wrapper script (in Python, portable) and invoking it as a custom target. It works and it is better than much of the CMake juggling. I think there are a lot of exaggerations around here. I have been a Meson user for long moving from CMake. CMake is quite more frustrating.
  - chombier 4y ago
    > I am not sure what stops you from using a wrapper script (in Python, portable) and invoking it as a custom target Nothing, when applicable this works and we're doing it already, thank you. But it doesn't as soon as one needs to abstract over CMake commands themselves (like add this target, set that target property, add this test and so on). Of course we could try to generate CMake files in wrapper scripts, but this is another level of CMake juggling entirely. > CMake is quite more frustrating. Could not agree more. But even more frustrating than CMake programming is Meson checking almost all the boxes yet refusing to provide that last one bit of functionality that would make me switch to it (and giving a wrong justification for it).
bogwog 4y ago
The ugly syntax is mostly a maintenance issue, but the real problem is that CMake doesn’t expose all of the internal build system “machinery” that you need to build something complex or performant. Take waf for example: it’s effectively a Python framework for creating a custom build system, with every single internal feature accessible (and documented) with good design instead of abstractions. In waf, you can do things like: * define custom build Tasks * have those Tasks spawn other Tasks dynamically (e.g. by parsing the stdout of a compiler to find output files) * Extend/modify the behavior of existing Task classes (e.g. the C/C++ linker) * Modify the task scheduler to control execution order * Implement commands that analyze your build scripts (e.g. to generate a compile_commands.json file, or anything else) * cache any serializable Python types between build invications * create reusable project-agnostic build scripts * wrap everything in a nice API so that build scripts are manageable * rich debugging features Not to mention the expressive syntax of Python and the full power of the standard library. And all you need is a Python interpreter (2.7 and 3+ both work), as Waf has zero dependencies. The learning curve is high, but it’s worth it for projects that have a lot of build complexity. In my case, I use CMake until a project needs custom functions, or needs to support multiple languages, then I switch to waf.
- oldgradstudent 4y ago
  Just curious, could you give a concrete example of what waf provides that CMake doesn't?
  - bogwog 4y ago
    Say your program requires some static data stored as XML files that link to each other (e.g. XLink), you need to convert them into a different in-memory representation, and then compile them into an object file for embedding into the binary, and maybe generate some header files to access the data. Maybe you even want to compress the data at build time, and link with zstd to decompress at runtime if the user passes a `--compress-data` flag when building. In waf, it's possible to implement everything you need for that in a highly efficient way: the 'scanner' method that parses XML files to find linked resources to setup dependencies, the task that generates the header file with optional decompression API, etc. Because the task scheduler is flexible and programmable, you can implement it so that nothing runs unless it absolutely has to. Even the dependency scanner can cache data between builds so that it doesn't need to re-scan for dependencies unless any of the files it found in a previous invocation changed (hash, timestamp, etc) For example: MyData.xml links to CoolStuff.xml; user modifies the whitespace of CoolStuff.xml, so MyData.xml needs to be rebuilt; the Task that converts it into a new representation runs, but since whitespace didn't affect the output of that task, the output file's hash is identical to what it was before, so the other tasks don't detect a change, and the build ends immediately. In CMake, it would be impossible to implement something comparable. With custom functions/external scripts you can technically do anything, but there's a lot of inefficiency both in runtime and development effort. Since CMake doesn't actually perform builds itself, it's limited in what you can directly do, and the DSL isn't powerful enough to take advantage of more flexible CMake internals even if they existed. But if you only need to compile C and C++ files with some light scripting, CMake is far superior for a lot of reasons.
bsder 4y ago
You just made a much better argument for why to use Meson than the Meson guys themselves made. At the end of the day, I don't want to have to know any build system let alone CMake. Period. Full stop. I want my build system to be declarative. That way, when it breaks, and it will break, I can fix the dumb thing. (Here's an example of the kind of breakage that CMake has: I can't compile with "zig cc" and friends, because there's a space in that compile command and CMake has baked-in parsing. Whoops. Yeah, CMake is slowly fixing that, but it's going to take forever to roll out a fix for something that shouldn't be in scope of the build system.) The fact that your project's build system needs complex features should be treated as a gigantic red klaxon to me, as a user, to stay far, far away from it. Needing to use complex features for build means that you need to reorganize your project and/or your "build system" needs to be broken apart into phases that are containing the complexity. I am picking on CMake here, but this is a failure of any build system that tries to do "too much". Cargo, from Rust, has similar problems.

chombier 4y ago

Same story here: complex build scripts in CMake, horrible language but at least it has some form(s) of user-defined abstraction. Tried to look into Meson, bumped into this issue, and decided against it for the same reason. I kinda get the rationale that no abstraction primitive should drive common patterns into the standard Meson distribution (an approach which has problems too, but at least it makes sense to me). However, seeing function definitions rejected on the basis of Turing-completeness raised serious doubts about the project at the time, and things haven't changed much on this front apparently[1] [1]: https://mesonbuild.com/Syntax.html#userdefined-functions-and-methods https://mesonbuild.com/Syntax.html#userdefined-functions-and...

germandiago 4y ago
I am not sure what stops you from using a wrapper script (in Python, portable) and invoking it as a custom target. It works and it is better than much of the CMake juggling. I think there are a lot of exaggerations around here. I have been a Meson user for long moving from CMake. CMake is quite more frustrating.
- chombier 4y ago
  > I am not sure what stops you from using a wrapper script (in Python, portable) and invoking it as a custom target Nothing, when applicable this works and we're doing it already, thank you. But it doesn't as soon as one needs to abstract over CMake commands themselves (like add this target, set that target property, add this test and so on). Of course we could try to generate CMake files in wrapper scripts, but this is another level of CMake juggling entirely. > CMake is quite more frustrating. Could not agree more. But even more frustrating than CMake programming is Meson checking almost all the boxes yet refusing to provide that last one bit of functionality that would make me switch to it (and giving a wrong justification for it).

bogwog 4y ago

The ugly syntax is mostly a maintenance issue, but the real problem is that CMake doesn’t expose all of the internal build system “machinery” that you need to build something complex or performant. Take waf for example: it’s effectively a Python framework for creating a custom build system, with every single internal feature accessible (and documented) with good design instead of abstractions. In waf, you can do things like: * define custom build Tasks * have those Tasks spawn other Tasks dynamically (e.g. by parsing the stdout of a compiler to find output files) * Extend/modify the behavior of existing Task classes (e.g. the C/C++ linker) * Modify the task scheduler to control execution order * Implement commands that analyze your build scripts (e.g. to generate a compile_commands.json file, or anything else) * cache any serializable Python types between build invications * create reusable project-agnostic build scripts * wrap everything in a nice API so that build scripts are manageable * rich debugging features Not to mention the expressive syntax of Python and the full power of the standard library. And all you need is a Python interpreter (2.7 and 3+ both work), as Waf has zero dependencies. The learning curve is high, but it’s worth it for projects that have a lot of build complexity. In my case, I use CMake until a project needs custom functions, or needs to support multiple languages, then I switch to waf.

oldgradstudent 4y ago
Just curious, could you give a concrete example of what waf provides that CMake doesn't?
- bogwog 4y ago
  Say your program requires some static data stored as XML files that link to each other (e.g. XLink), you need to convert them into a different in-memory representation, and then compile them into an object file for embedding into the binary, and maybe generate some header files to access the data. Maybe you even want to compress the data at build time, and link with zstd to decompress at runtime if the user passes a `--compress-data` flag when building. In waf, it's possible to implement everything you need for that in a highly efficient way: the 'scanner' method that parses XML files to find linked resources to setup dependencies, the task that generates the header file with optional decompression API, etc. Because the task scheduler is flexible and programmable, you can implement it so that nothing runs unless it absolutely has to. Even the dependency scanner can cache data between builds so that it doesn't need to re-scan for dependencies unless any of the files it found in a previous invocation changed (hash, timestamp, etc) For example: MyData.xml links to CoolStuff.xml; user modifies the whitespace of CoolStuff.xml, so MyData.xml needs to be rebuilt; the Task that converts it into a new representation runs, but since whitespace didn't affect the output of that task, the output file's hash is identical to what it was before, so the other tasks don't detect a change, and the build ends immediately. In CMake, it would be impossible to implement something comparable. With custom functions/external scripts you can technically do anything, but there's a lot of inefficiency both in runtime and development effort. Since CMake doesn't actually perform builds itself, it's limited in what you can directly do, and the DSL isn't powerful enough to take advantage of more flexible CMake internals even if they existed. But if you only need to compile C and C++ files with some light scripting, CMake is far superior for a lot of reasons.

bsder 4y ago

You just made a much better argument for why to use Meson than the Meson guys themselves made. At the end of the day, I don't want to have to know any build system let alone CMake. Period. Full stop. I want my build system to be declarative. That way, when it breaks, and it will break, I can fix the dumb thing. (Here's an example of the kind of breakage that CMake has: I can't compile with "zig cc" and friends, because there's a space in that compile command and CMake has baked-in parsing. Whoops. Yeah, CMake is slowly fixing that, but it's going to take forever to roll out a fix for something that shouldn't be in scope of the build system.) The fact that your project's build system needs complex features should be treated as a gigantic red klaxon to me, as a user, to stay far, far away from it. Needing to use complex features for build means that you need to reorganize your project and/or your "build system" needs to be broken apart into phases that are containing the complexity. I am picking on CMake here, but this is a failure of any build system that tries to do "too much". Cargo, from Rust, has similar problems.