5 ms·

The excuse is still wrong, and indicates complete misunderstanding of what Turing-complete means. I write plugins for a large, well known application. Buildin

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.
        bonzini 4y ago
        QEMU also has a complicated multi stage build process, and using foreach was not a workaround. Each directory sets up what it wants to build in a dictionary, and then the main meson.build does all the steps.
  - palata 4y ago
    Does CMake have to generate the file and pass it through the special compiler? Can't it be done separately, before CMake is run? One thing that I find make CMake configurations completely unreadable is to try to have it do everything, coffee included. Where often a script could be run separately first (e.g. to generate those files), and then CMake could run normally afterwards.
    - oldgradstudent 4y ago
      > Does CMake have to generate the file and pass it through the special compiler? Can't it be done separately, before CMake is run? No, it cannot be done before CMake runs. It is a target like any other build target. It depends on other files or targets, and should be rerun if any of them change, and if it is rebuilt, there are other targets that depend on it and should be rebuilt, and so on. The entire point of the build system is to concisely and accurate specify the build graph, and only rebuild what is necessary.
      - palata 4y ago
        Ok let's take a concrete example. Say you have proto files (seems likely in a big system). Whenever you change a proto file, you know that you should run protoc, and then run CMake. If you add a proto file, not only you need to run protoc on this new file, but you need to tell CMake about the new generated file(s). For the big majority of projects out there, it seems to me that it is perfectly fine to handle that manually, because projects are not that big. Do we agree on that? Then of course, if you are a GAFAM with a huge monorepo, probably you need more advanced tools (they don't build their own tools for nothing). My feeling, though, is that most people complaining that CMake is crap actually work on small projects and can't be bothered to run protoc manually "because their philosophy is that it should all work with one button".
        plorkyeran 4y ago
        No, I don't agree that having to manually run protoc after modifying a proto file is even slightly reasonable. That is exactly the sort of thing which the build system is there for, and the idea of not spending the few minutes it takes to automate that is baffling to me.
  - junon 4y ago
    Don't bother arguing with Meson contributors. The typical response to realistic use cases like this is to gaslight you into thinking you're doing something wrong.
    - oldgradstudent 4y ago
      LOL There is definitely a religious feeling to some of their arguments.
    - bonzini 4y ago
      Not necessarily wrong, but you might have to try doing things differently and it might work or not. Meson is certainly less mature than CMake, on the other hand it's much harder to go down a rabbit hole of "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should" and consequent technical debt. I can see how that can be frustrating. My experience with QEMU's transition to meson is that it was clear from the beginning that Meson would not be able to do everything we needed, but it would let us focus on the few things that are special (e.g. building tests for dozens of targets using dozens of cross compilers) and simplify everything else. It was not easy: it involved several contributions to meson itself (that everybody now benefits from, for example Postgres), and we do have to live with a couple limitations of the tool, but the outcome was extremely positive: * 4000 less lines of build system gunk * A lot fewer requests for help even from experienced developers * Several new features that required build system hacking could be implemented much more easily * A transition that did not a require any learning curve for existing developers, because trivial changes to the build system remained trivial Of course there is still complexity, QEMU still has 11000 lines of build system code. But it was totally worth it.
      - oldgradstudent 4y ago
        I'm sure it is better than the previous system, otherwise QEMU would not be migrated to Meson. But, you're describing a 11,000 line program without the most basic abstraction mechanism known to man - user defined functions. What are the benefits of not having user defined functions? none, zilch, nada. The Meson team is grasping at straws trying to claim that having user-defined functions would make it Turing-complete. Without recursion, it won't. Try to imagine how you would structure those 11,000 lines of code if user-defined functions were available? Would you really write it without extensive use of functions?
  - germandiago 4y ago
    AFAIK this can be done with a mix of custom targets and adding the result to the input of the shared lib in some way. What thing you cannot do? I have used capnproto, generated c++ files and passed the result to the input of targets perfectly ok.
    - oldgradstudent 4y ago
      Of course O can do that. The point is that I want to do it many times over, in different places in my code. What I want to do is to spend the time and effort in understanding and debugging the process, and then encapsulating it in a single function call. Then completely forget about the details and use that single function call. What is the advantage in not having user-defined functions? None, zilch, nada.

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.
        bonzini 4y ago
        QEMU also has a complicated multi stage build process, and using foreach was not a workaround. Each directory sets up what it wants to build in a dictionary, and then the main meson.build does all the steps.
- palata 4y ago
  Does CMake have to generate the file and pass it through the special compiler? Can't it be done separately, before CMake is run? One thing that I find make CMake configurations completely unreadable is to try to have it do everything, coffee included. Where often a script could be run separately first (e.g. to generate those files), and then CMake could run normally afterwards.
  - oldgradstudent 4y ago
    > Does CMake have to generate the file and pass it through the special compiler? Can't it be done separately, before CMake is run? No, it cannot be done before CMake runs. It is a target like any other build target. It depends on other files or targets, and should be rerun if any of them change, and if it is rebuilt, there are other targets that depend on it and should be rebuilt, and so on. The entire point of the build system is to concisely and accurate specify the build graph, and only rebuild what is necessary.
    - palata 4y ago
      Ok let's take a concrete example. Say you have proto files (seems likely in a big system). Whenever you change a proto file, you know that you should run protoc, and then run CMake. If you add a proto file, not only you need to run protoc on this new file, but you need to tell CMake about the new generated file(s). For the big majority of projects out there, it seems to me that it is perfectly fine to handle that manually, because projects are not that big. Do we agree on that? Then of course, if you are a GAFAM with a huge monorepo, probably you need more advanced tools (they don't build their own tools for nothing). My feeling, though, is that most people complaining that CMake is crap actually work on small projects and can't be bothered to run protoc manually "because their philosophy is that it should all work with one button".
      - plorkyeran 4y ago
        No, I don't agree that having to manually run protoc after modifying a proto file is even slightly reasonable. That is exactly the sort of thing which the build system is there for, and the idea of not spending the few minutes it takes to automate that is baffling to me.
- junon 4y ago
  Don't bother arguing with Meson contributors. The typical response to realistic use cases like this is to gaslight you into thinking you're doing something wrong.
  - oldgradstudent 4y ago
    LOL There is definitely a religious feeling to some of their arguments.
  - bonzini 4y ago
    Not necessarily wrong, but you might have to try doing things differently and it might work or not. Meson is certainly less mature than CMake, on the other hand it's much harder to go down a rabbit hole of "Your scientists were so preoccupied with whether they could, they didn't stop to think if they should" and consequent technical debt. I can see how that can be frustrating. My experience with QEMU's transition to meson is that it was clear from the beginning that Meson would not be able to do everything we needed, but it would let us focus on the few things that are special (e.g. building tests for dozens of targets using dozens of cross compilers) and simplify everything else. It was not easy: it involved several contributions to meson itself (that everybody now benefits from, for example Postgres), and we do have to live with a couple limitations of the tool, but the outcome was extremely positive: * 4000 less lines of build system gunk * A lot fewer requests for help even from experienced developers * Several new features that required build system hacking could be implemented much more easily * A transition that did not a require any learning curve for existing developers, because trivial changes to the build system remained trivial Of course there is still complexity, QEMU still has 11000 lines of build system code. But it was totally worth it.
    - oldgradstudent 4y ago
      I'm sure it is better than the previous system, otherwise QEMU would not be migrated to Meson. But, you're describing a 11,000 line program without the most basic abstraction mechanism known to man - user defined functions. What are the benefits of not having user defined functions? none, zilch, nada. The Meson team is grasping at straws trying to claim that having user-defined functions would make it Turing-complete. Without recursion, it won't. Try to imagine how you would structure those 11,000 lines of code if user-defined functions were available? Would you really write it without extensive use of functions?
- germandiago 4y ago
  AFAIK this can be done with a mix of custom targets and adding the result to the input of the shared lib in some way. What thing you cannot do? I have used capnproto, generated c++ files and passed the result to the input of targets perfectly ok.
  - oldgradstudent 4y ago
    Of course O can do that. The point is that I want to do it many times over, in different places in my code. What I want to do is to spend the time and effort in understanding and debugging the process, and then encapsulating it in a single function call. Then completely forget about the details and use that single function call. What is the advantage in not having user-defined functions? None, zilch, nada.