[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