Re: [PATCH v12 1/7] buildtools/chkincs: relax C linkage requirement

[Bruce Richardson <bruce.richardson@intel.com>]

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