Meson: Add limited user-defined functions?

[mkrogius]

In order to reduce copy and pasting it would be useful to be able to define functions. I agree that it would be a bad thing to make meson turing-complete, so why not allow user-defined functions, but with the restriction that a user-defined function may not call any other user-defined function.

[koteyur]

Agree. Restrict recursion (and indirect recursion). Restrict storing function in variables. So language will stay turing-incomplete.

[le-jzr]

It would also help me a great deal.

The simplest way to do this is probably to have the following restrictions:

• User-defined function must be defined before it is used.
• It is considered defined after the _end of the body_.
• User-defined function may not be changed or redefined.
  
  
  
  • Alternatively, their names can be bound to a new function, but any prior reference keeps pointing to the old definition.
  
  

That way, recursion is impossible, parsing is simple, and it adds no expressive power to the language (you can do the same functionality by inlining all such functions).

[le-jzr]

Would such restricted functions/macros be categorically unwanted, or can I take a shot at implementing it?

[jpakkane]

User defined functions will not be accepted. End of discussion.

What you can do instead is to add functionality that provides what you were going to do with your functions and submit that as a pull request instead if it is generally useful. This way everyone can use it.

[koteyur]

Thanks for the detailed explanation. Now it is obvious why user defined functions are not needed.

[jpakkane]

Now obviously we can't accept every niche thing in Meson master but we can add general tools that people can use to solve their own problems. The UX won't (and can't) be perfect but unfortunately everything is a tradeoff.

[le-jzr]

I accept the decision, user-defined functions won't happen, message received.

But I feel obligated to say you are contradicting yourself. You say we should add niche tools for everyone to use instead of general functionality that people can solve their own problems with, then the next message says the exact opposite.

[mkrogius]

If the decision is that no user-defined functions will be allowed, how do you propose that we reduce duplication of code in build files? The reason I originally posted this question is because I have 68 lines of meson code that I have to copy paste in a bunch of places. Adding user-defined functions or even just simple macros would help a lot here.

[ePirat]

Can you maybe given an example of your usecase? For VLC for example I managed to get rid of a lot of repetition by using an array of dictionaries and iterating over them.

[textshell]

For VLC for example I managed to get rid of a lot of repetition by using an array of dictionaries and iterating over them.

I know this is currently the recommended way, but i always feel like that is a work around. Not something that really promotes the spirit of meson being easy and obvious to use.

[mkrogius]

@ePirat Sure! I'm happy to have more experienced mesoners take a look.

What this build file does is:

• it generates c code for my LCM message definitions in both the source and build folders (because reasons)
• compiles the c code into a dependency
• generates python files from the LCM message definitions
• compiles, zips, and installs the python files.

This exact same code ends up in a bunch of different places since I have a bunch of different folders which contain LCM files that need to be processed. It used to be more lines of meson code until I gave up and made a python script that does all of the steps for the python files at once.

The Meson file: https://gist.github.com/mkrogius/56fadc42cf0b551ba414accfa1dfb488
The python script I made to reduce the size of the meson file: https://gist.github.com/mkrogius/fb6c6c84bbb9c692c7a35f524d50cf66

Ideally I would just have to define all the necessary processing steps for my LCM files once, and then use that definition everywhere else in my project.

For clarity, by LCM I mean this project: https://lcm-proj.github.io/

[tp-m]

For what it's worth, there is also PR #5209 which adds an include() function which might help in some cases with managing duplication/repeated chunks.

[TheQwertiest]

Not exactly - #5209 does not allow multiple inclusions of the same file, since it would be equal to function/macros, which are not allowed in meson by design. That PR main purpose is flat layout of split meson.build files (that is multiple split build files in one directory instead of one very long build file and/or multiple subdirectories for each split build file).