Re: [PATCH for-4.21] tools/tests: don't pass -E to sed

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.10.2025 17:07, Roger Pau Monné wrote:
> On Wed, Oct 08, 2025 at 04:42:13PM +0200, Jan Beulich wrote:
>> On 08.10.2025 16:30, Roger Pau Monné wrote:
>>> On Wed, Oct 08, 2025 at 11:47:05AM +0200, Jan Beulich wrote:
>>>> Even the 2018 edition of The Open Group Base Specifications Issue 7 [1]
>>>> doesn't name -E as a standard option; only Issue 8 [2] does. As there's
>>>> nothing "extended" about the expression used, simply drop the -E.
>>>>
>>>> [1] https://pubs.opengroup.org/onlinepubs/9699919799/
>>>> [2] https://pubs.opengroup.org/onlinepubs/9799919799/
>>>>
>>>> Fixes: cb50e4033717 ("test/pdx: add PDX compression unit tests")
>>>> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
>>>
>>> Reviewed-by: Roger Pau Monné <roger.pau@xxxxxxxxxx>
>>
>> Thanks.
>>
>>>> ---
>>>> In principle the -e could be dropped too, for being redundant.
>>>>
>>>> Hitting the problem with an older sed pointed out another problem here as
>>>> well: The failed invocation left a 0-byte pdx.h, which upon re-invocation
>>>> of make was (obviously) deemed up-to-date, thus causing the build to fail
>>>> again (until the bad file was actually removed).
>>>
>>> Hm, we could do something like:
>>>
>>> sed -e '/^#[[:space:]]*include/d' <$< >$@ || $(RM) $@
>>
>> As is that would hide failure of the sed invocation from make. I was first
>> thinking to sed into a temporary file, to then rename that file. But this
>> won't cover the more general case of the issue either.
> 
> Well, it would work if the sed into temporary file is a FORCE target,
> and then the move to the final file is only done if there are
> differences?

Yes, splitting like this ought to do.

>> Meanwhile I think
>> that the Makefile itself should become a dependency of the of the target
>> header. That way, if the sed expression changes, the file will be rebuilt.
>> (Of course this still builds on an assumption, specifically that any
>> failure here would be dealt with by an adjustment to the rule. So possibly
>> we need a combination of both.)
> 
> It feels weird to me that a Makefile depends on itself, but yes, it
> might solve the issue you pointed out in a simpler way.  Doesn't
> makefile consider all make generated targets as obsolete if the
> makefile itself changes?

I don't think so, no. What it feels a little as if you may be thinking of
is that if a Makefile itself is a target, make will re-invoke itself once
it was updated.

>  The pdx.h generation is a clear example
> here, but the same could apply to runes used to build object files?

Well, yes. That's why we have the .*.cmd files in the hypervisor build
system. That's less coarse than using the full Makefile-s as dependencies.

Jan