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 <[email protected]> > > > > Reviewed-by: Roger Pau Monné <[email protected]> > > 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.
