On Thu, Oct 10, 2024 at 12:24:25PM +0200, Mattias Rönnblom wrote: > On 2024-10-06 17:58, Robin Jarry wrote: > > Mattias Rönnblom, Oct 06, 2024 at 16:17: > > > > I think you need to change run_command() to custom_target(). I > > > > was thinking of this patch to be much simpler as follows: > > > > > > I started off with a shell script, but I switched to Python when I > > > wanted to strip off comments. (Not that that can't be done in bourne > > > shell.) > > > > > > The below script doesn't strip off comments, and provides no usage > > > information. Earlier I got the impression you wanted to improve > > > command-line usage. > > > > > > I think we need to decide if this thing is an integral part of the > > > build system, custom-made for its needs, or if its something that > > > should also be friendly to a command-line human user. > > > > > > I could go either way on that. > > > > We don't have to choose. Being part of the build system does not mean > > If it's an integral part of the build system, and the only user is another > program (e.g., meson.build), the script can be made simpler. For example, > you need not bother with usage information, since a computer program will > not have any use of it. > > It would be helpful if Bruce could comment on this. How should we think > about small tools like this? That are more-or-less just an artifact of the > lack of expressiveness in meson. > > I'm leaning toward having them as proper human-usable CLI tools, provided it > doesn't cause too much fuzz on the meson.build side of things. >
I don't have a strong opinion either way. Meson indeed (like make before it) has a limited set of basic things it can do, and requires scripting to augment that. Whether those script are only for meson use or should be usable outside the build I think we can determine on a case-by-case basis. Initially, I would myself tend toward having them build-system-only for simplicity, and only later generalise if there is a case for it (YAGNI principle). However, if you think that a script may be better usable both as part of a build and as a standalone tool, I see no issues with early generalization - especially if the added complexity is minimal! /Bruce
