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

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

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?

> 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?  The pdx.h generation is a clear example
here, but the same could apply to runes used to build object files?

Thanks, Roger.