On 2024-10-06 10:55, Mattias Rönnblom wrote:
On 2024-10-04 13:51, Robin Jarry wrote:
Mattias Rönnblom, Oct 04, 2024 at 10:40:
Making small scripts needlessly complicated is not good example, it's
a bad one.
I don't find adding argument checks needlessly complicated but this is
a matter of preference. To me, Python is not shell script. If you want
something small, shell might be more appropriate?
Python can serve in many roles. I suggest you be more pragmatic and
sensitive to the context. Sometimes the non-existence/non-use of doc
strings and other language features that makes sense in larger programs
is not a sign of the author being out to "treat Python badly".
Sure, but it would be required to invoke the script for every
header file in the tree. Not sure I think that would be a net gain.
You can store a global exit status in the script and process all
headers before exiting with an error if any.
You will need to give the user a list of offending header files.
I'm not suggesting to avoid printing the offending file names. I'm
only suggesting to exit(1) if there were *any* offending file names.
That way you don't have to check *in meson* if the script did output
anything. Checking the exit status is simpler.
What you wrote was "/../ That way you would not have to capture stdout
at all and you could leave meson do the work.".
Can you elaborate on this? I'm not sure I follow. Is there a way to not
capture the script output, invoke the script only once per build, and
yet produce a fine-grained error message to the user?
I agree properly setting the exit code is an improvement. I just don't
see how that materially changes anything on the meson side of things.
But then, I know nothing about meson.
OK, so it does change something, but not for the better, seemingly.
meson.build now somehow has to distinguished between two different "errors":
1) One or more offending header files were found.
2) Any other kind of error (file not found, access control issues,
internal script error, etc).
For 1), it should print a list of the offending header files.
If you just set "check: true" in run_command(), and have the
chkextern.py script return non-zero on error, the offending header files
will not be printed on stdout.
My guess would be that this complicating factor is the reason for this
pattern of not (in/from meson) depending on the script delegate exit
code, but rather the output.
May I should rename the script to "scanextern.py" to better reflect that
a failure to find an issue is not an error (=non-zero exit code).
Sorry for being pedantic, but Python code in DPDK is already treated
badly. I wish we could improve the quality a bit.
Cheers.
