[PATCH v12 1/7] buildtools/chkincs: relax C linkage requirement
Mattias Rönnblom
hofors at lysator.liu.se
Sun Oct 6 11:47:35 CEST 2024
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.
>>
>
More information about the dev
mailing list