8 ms·

Meson still won't have user defined functions, and gives a bad excuse: > Meson does not currently support user-defined functions or methods. The addition of us

Meson still won't have user defined functions, and gives a bad excuse: > Meson does not currently support user-defined functions or methods. The addition of user-defined functions would make Meson Turing-complete which would make it harder to reason about and more difficult to integrate with tools like IDEs. No, user-defined functions won't make Meson Turing-complete as long as recursion is not allowed. User defined functions make it easier to encapsulate complicated build logic and reuse it.

tristan957 4y ago
If the only reason to use CMake is user-defined functions, I see no real reason to use it. The gains in readability of Meson are far and beyond the gains of user-defined functions in my opinion. I maintain a large open source library and haven't once felt the need for user-defined functions.
- oldgradstudent 4y ago
  The excuse is still wrong, and indicates complete misunderstanding of what Turing-complete means. I write plugins for a large, well known application. Building the plugin is a complicated multi stage process with many dependencies. I've spent a lot of time understanding the process (undocumented, only VS and Xcode project files are provided in the SDK). I now have a single function call to create each plugin.
  - tristan957 4y ago
    What is hard about the following? # project/meson.build project_plugin_dep = declare_dependency( include_directories: plugin_includes, compile_args: plugin_c_args ) # plugin/meson.build, repeated for each plugin shared_module( 'plugin', 'plugin.c', dependencies: project_plugin_dep ) Without having seen what your user-defined function does, this is the best equivalent that I can come up with. If your plugins exist out of tree, then Meson can consume a pkg-config file. Postgres is slowly moving to Meson and uses out of tree plugins.
    - oldgradstudent 4y ago
      I also need to generate a file, pass it through a special compiler, pass the result through the system resource compiler, link it with the shared library. There are a bunch of other steps. I have a YAML description of the plugin which I use to generate plugin skeleton, and so on. Do you really think it makes sense to repeat that again and again? And then, what if I need to fix a bug in the process?
      - bonzini 4y ago
        Can you use a foreach loop?
        oldgradstudent 4y ago
        I'm sure I can use any number of ugly workarounds. In many large projects, the build system is necessarily large and complicated. It should be treated like any other code, and would massively benefit from the most basic tool for writing clean, readable code - user-defined functions. Sadly, as much as Meson is tempting in other respects, without user-defined functions, it is unfit for human consumption. The excuse Meson uses, that user-defined functions would make it Turing-complete and therefore not statically analyzable is totally false. Adding user-defined functions without recursion does not make the language Turing-complete. On the contrary, as long as there is no recursion, you can inline the functions and create an equivalent code without functions.
        tristan957 4y ago
        > it is unfit for human consumption. Surely this is hyperbole since some of the largest open source projects consider it a viable build system. Systemd, Mesa, GStreamer, GNOME, Postgres. Would I be correct in assuming that you are coming at this conversation having never tried Meson?
        oldgradstudent 4y ago
        > Would I be correct in assuming that you are coming at this conversation having never tried Meson? I tried to port the project I've previously mentioned here from CMake to Meson build, but could not find a way of doing it with Meson build in a satisfactory way. The lack of user-defined functions is a show stopper because I have a complicated multis-stage build process. It is also very different between platform. Having to repeat parts of this process is disqualifying. A programming language, and a build language is a programming language, without user-defined functions is unfit for human consumption.
palata 4y ago
Is it really a bad excuse, or is it a polite way to say "Why the hell do you need user-defined functions?". At least that's how I would say it myself.
- oldgradstudent 4y ago
  The reason you need functions anywhere else. Encapsulate complicated build logic and reuse it.
  - palata 4y ago
    Sure, I just question what kind of complicated logic you want to put in there.
    - oldgradstudent 4y ago
      See my other response: https://news.ycombinator.com/item?id=34111709 https://news.ycombinator.com/item?id=34111709
    - frankzinger 4y ago
      Big projects have complicated builds. Here is just one file out of dozens (or hundreds?) that make up Qt's build: https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtModuleHelpers.cmake https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtModuleHel....
      - palata 4y ago
        Sure. My point is that most projects are not big projects. And most people complaining about CMake are probably not working on big project either. Just look around in this thread: people don't say "I use Meson because I work in a GAFAM-sized project", but rather "Meson is soooo infinitely better because the syntax feels more natural to me".
bogwog 4y ago
If you need custom build functions like that, neither Meson nor CMake are a good choice. If you have complicated build logic, you'd be better off with something more advanced, like scons, waf, bazel, ant, buck, etc.
- oldgradstudent 4y ago
  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).
foresto 4y ago
Anecdote: While backporting a new PipeWire release earlier this year, I discovered that it had added dependencies on new Meson features that didn't exist in Debian Stable. User-defined functions would have allowed me to shim those features on the older Meson version, greatly simplifying my work and minimizing my patches' footprint. I don't know if that situation is common enough to justify user-defined functions to Meson's author, but it was frustrating, and it seemed ironic that a build system designed to solve platform compatibility problems had in some sense become one.
- bonzini 4y ago
  Yeah that's a case where functions could be useful but I think the real problem there is the non-perfect backwards compatibility in Meson, which makes it unnecessarily hard to include new versions of it in stable distros. The main culprit is GNOME packages because they were early adopters of Meson and thus had a few incorrect idioms that were cargo culted to a few dozen packages. For a similar issue in RHEL we decided to update Meson, but we needed to revert some changes that tightened the language. I do plan to include those changes in Meson in the near future, keyed on the minimum version in the "project" line, so that older packages are easier to build with newer Meson. That said, did you consider backporting the new features to the older Meson in Debian stable?
  - foresto 4y ago
    > did you consider backporting the new features to the older Meson in Debian stable? No, since modifying an additional project would run counter to the goal of minimizing the scope of the backport's changes. (Especially important when said project is a dependency of other packages, and could potentially break other things on the distro. This was Debian Stable, after all.)
- Flowdalic 4y ago
  It should be possible to install meson via pip --user. Even though I prefer system-wide installations, I believe this weakens your argument for user defined functions in your situation.
matheusmoreira 4y ago
I don't think it's a bad excuse at all. Limiting computational power as much as possible is a good thing as demonstrated by https://langsec.org/ https://langsec.org/.
- oldgradstudent 4y ago
  User defined functions without recrsion do not increase computational power. And they definitely don't make a language Turing-complete. They just make large code bases tractable for humans.
pron 4y ago
> No, user-defined functions won't make Meson Turing-complete as long as recursion is not allowed. Turing-completeness is, itself, often a red herring. What it alludes to is the difficulty in predicting what a program would do because, in the general case, it is impossible to tell what behaviour a program in a Turing-complete language would exhibit for a particular input short of observing what it actually does. But even languages that are not Turing-complete often fall far beyond what is practically predictable. While theoretically decidable, predicting what a program written in a language with nothing but boolean variables and loops of no more than two iterations, or, alternatively, functions of boolean parameters even without recursion, is PSPACE-complete (as such a language can easily encode TQBF [1]). I.e. predicting how such a program would behave is computationally intractable, since it grows exponentially with the size of the program. Programs in such a language would also fall outside the capabilities of heuristic methods, such as SAT solvers, to tackle (SAT is merely NP-hard compared to the strictly harder PSPACE-hard TQBF). So if your language has variables and loops (even limited to two iterations), or variables and functions (even without recursion) -- it's intractable, even though it's not Turing-complete. I don't know whether this particular language qualifies or not. [1]: https://en.wikipedia.org/wiki/True_quantified_Boolean_formula https://en.wikipedia.org/wiki/True_quantified_Boolean_formul...
- oldgradstudent 4y ago
  The current language has loops and Boolean variables. It is trivial to reduce a TQBF formula into a Meson program. The entire issue is a red herring. They climbed up a tree and can't climb down without losing face. The correct way to handle the situation is to make the change, wait for everyone to cool down, and then pretend that was their position all along.

tristan957 4y ago

If the only reason to use CMake is user-defined functions, I see no real reason to use it. The gains in readability of Meson are far and beyond the gains of user-defined functions in my opinion. I maintain a large open source library and haven't once felt the need for user-defined functions.

oldgradstudent 4y ago
The excuse is still wrong, and indicates complete misunderstanding of what Turing-complete means. I write plugins for a large, well known application. Building the plugin is a complicated multi stage process with many dependencies. I've spent a lot of time understanding the process (undocumented, only VS and Xcode project files are provided in the SDK). I now have a single function call to create each plugin.
- tristan957 4y ago
  What is hard about the following? # project/meson.build project_plugin_dep = declare_dependency( include_directories: plugin_includes, compile_args: plugin_c_args ) # plugin/meson.build, repeated for each plugin shared_module( 'plugin', 'plugin.c', dependencies: project_plugin_dep ) Without having seen what your user-defined function does, this is the best equivalent that I can come up with. If your plugins exist out of tree, then Meson can consume a pkg-config file. Postgres is slowly moving to Meson and uses out of tree plugins.
  - oldgradstudent 4y ago
    I also need to generate a file, pass it through a special compiler, pass the result through the system resource compiler, link it with the shared library. There are a bunch of other steps. I have a YAML description of the plugin which I use to generate plugin skeleton, and so on. Do you really think it makes sense to repeat that again and again? And then, what if I need to fix a bug in the process?
    - bonzini 4y ago
      Can you use a foreach loop?
      - oldgradstudent 4y ago
        I'm sure I can use any number of ugly workarounds. In many large projects, the build system is necessarily large and complicated. It should be treated like any other code, and would massively benefit from the most basic tool for writing clean, readable code - user-defined functions. Sadly, as much as Meson is tempting in other respects, without user-defined functions, it is unfit for human consumption. The excuse Meson uses, that user-defined functions would make it Turing-complete and therefore not statically analyzable is totally false. Adding user-defined functions without recursion does not make the language Turing-complete. On the contrary, as long as there is no recursion, you can inline the functions and create an equivalent code without functions.
        tristan957 4y ago
        > it is unfit for human consumption. Surely this is hyperbole since some of the largest open source projects consider it a viable build system. Systemd, Mesa, GStreamer, GNOME, Postgres. Would I be correct in assuming that you are coming at this conversation having never tried Meson?
        oldgradstudent 4y ago
        > Would I be correct in assuming that you are coming at this conversation having never tried Meson? I tried to port the project I've previously mentioned here from CMake to Meson build, but could not find a way of doing it with Meson build in a satisfactory way. The lack of user-defined functions is a show stopper because I have a complicated multis-stage build process. It is also very different between platform. Having to repeat parts of this process is disqualifying. A programming language, and a build language is a programming language, without user-defined functions is unfit for human consumption.

palata 4y ago

Is it really a bad excuse, or is it a polite way to say "Why the hell do you need user-defined functions?". At least that's how I would say it myself.

oldgradstudent 4y ago
The reason you need functions anywhere else. Encapsulate complicated build logic and reuse it.
- palata 4y ago
  Sure, I just question what kind of complicated logic you want to put in there.
  - oldgradstudent 4y ago
    See my other response: https://news.ycombinator.com/item?id=34111709 https://news.ycombinator.com/item?id=34111709
  - frankzinger 4y ago
    Big projects have complicated builds. Here is just one file out of dozens (or hundreds?) that make up Qt's build: https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtModuleHelpers.cmake https://code.qt.io/cgit/qt/qtbase.git/tree/cmake/QtModuleHel....
    - palata 4y ago
      Sure. My point is that most projects are not big projects. And most people complaining about CMake are probably not working on big project either. Just look around in this thread: people don't say "I use Meson because I work in a GAFAM-sized project", but rather "Meson is soooo infinitely better because the syntax feels more natural to me".

bogwog 4y ago

If you need custom build functions like that, neither Meson nor CMake are a good choice. If you have complicated build logic, you'd be better off with something more advanced, like scons, waf, bazel, ant, buck, etc.

oldgradstudent 4y ago
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).

foresto 4y ago

Anecdote: While backporting a new PipeWire release earlier this year, I discovered that it had added dependencies on new Meson features that didn't exist in Debian Stable. User-defined functions would have allowed me to shim those features on the older Meson version, greatly simplifying my work and minimizing my patches' footprint. I don't know if that situation is common enough to justify user-defined functions to Meson's author, but it was frustrating, and it seemed ironic that a build system designed to solve platform compatibility problems had in some sense become one.

bonzini 4y ago
Yeah that's a case where functions could be useful but I think the real problem there is the non-perfect backwards compatibility in Meson, which makes it unnecessarily hard to include new versions of it in stable distros. The main culprit is GNOME packages because they were early adopters of Meson and thus had a few incorrect idioms that were cargo culted to a few dozen packages. For a similar issue in RHEL we decided to update Meson, but we needed to revert some changes that tightened the language. I do plan to include those changes in Meson in the near future, keyed on the minimum version in the "project" line, so that older packages are easier to build with newer Meson. That said, did you consider backporting the new features to the older Meson in Debian stable?
- foresto 4y ago
  > did you consider backporting the new features to the older Meson in Debian stable? No, since modifying an additional project would run counter to the goal of minimizing the scope of the backport's changes. (Especially important when said project is a dependency of other packages, and could potentially break other things on the distro. This was Debian Stable, after all.)
Flowdalic 4y ago
It should be possible to install meson via pip --user. Even though I prefer system-wide installations, I believe this weakens your argument for user defined functions in your situation.

matheusmoreira 4y ago

I don't think it's a bad excuse at all. Limiting computational power as much as possible is a good thing as demonstrated by https://langsec.org/ https://langsec.org/.

oldgradstudent 4y ago
User defined functions without recrsion do not increase computational power. And they definitely don't make a language Turing-complete. They just make large code bases tractable for humans.

pron 4y ago

> No, user-defined functions won't make Meson Turing-complete as long as recursion is not allowed. Turing-completeness is, itself, often a red herring. What it alludes to is the difficulty in predicting what a program would do because, in the general case, it is impossible to tell what behaviour a program in a Turing-complete language would exhibit for a particular input short of observing what it actually does. But even languages that are not Turing-complete often fall far beyond what is practically predictable. While theoretically decidable, predicting what a program written in a language with nothing but boolean variables and loops of no more than two iterations, or, alternatively, functions of boolean parameters even without recursion, is PSPACE-complete (as such a language can easily encode TQBF [1]). I.e. predicting how such a program would behave is computationally intractable, since it grows exponentially with the size of the program. Programs in such a language would also fall outside the capabilities of heuristic methods, such as SAT solvers, to tackle (SAT is merely NP-hard compared to the strictly harder PSPACE-hard TQBF). So if your language has variables and loops (even limited to two iterations), or variables and functions (even without recursion) -- it's intractable, even though it's not Turing-complete. I don't know whether this particular language qualifies or not. [1]: https://en.wikipedia.org/wiki/True_quantified_Boolean_formula https://en.wikipedia.org/wiki/True_quantified_Boolean_formul...

oldgradstudent 4y ago
The current language has loops and Boolean variables. It is trivial to reduce a TQBF formula into a Meson program. The entire issue is a red herring. They climbed up a tree and can't climb down without losing face. The correct way to handle the situation is to make the change, wait for everyone to cool down, and then pretend that was their position all along.