On Tue, Sep 29 2026 at 18:56:26 +02:00:00, Alexander Kanavin 
<alex.kanavin@gmail.com> wrote:
> Why is it failing? Shouldn't we fix the fail instead of suppressing 
> the regeneration?
> 
> Alex

The failure is intentional on MakeMaker side. This is the rule it 
writes into every Makefile

$(FIRST_MAKEFILE) : Makefile.PL $(CONFIGDEP)
      $(NOECHO) $(ECHO) "Makefile out-of-date with respect to $?"
      ...
      -$(NOECHO) $(MV)   $(FIRST_MAKEFILE) $(MAKEFILE_OLD)
      - $(MAKE) $(USEMAKEFILE) $(MAKEFILE_OLD) clean $(DEV_NULL)
      $(PERLRUN) Makefile.PL <original args>
      $(NOECHO) $(ECHO) "==> Your Makefile has been rebuilt. <=="
      $(NOECHO) $(ECHO) "==> Please rerun the $(MAKE) command.  <=="
      $(FALSE)

The only way to "fix the fail" is to run make a second time. That is 
what the first version did

Regenerating the Makefile inside do_compile/do_install is not correct 
for us because it skips the do_configure fixups.
The trigger is only a timestamp. CONFIGDEP is Config.pm and config.h of 
the staged perl. do_prepare_recipe_sysroot re-stages them, and the 
FIXMESTAGINGDIR sed in staging.bbclass rewrites them, so they get a new 
mtime even though their content matches what do_configure saw. If perl 
really changes, the task hash changes and bitbake reruns do_configure 
anyway. That path does apply the fixups.

The correct way to regenerate the Makefile is do_configure, and bitbake 
already takes care of that. Clearing CONFIGDEP only stops make from 
reacting to a timestamp that means nothing inside a bitbake build. 
Makefile.PL itself stays a dependency, so a changed Makefile.PL would 
still be noticed.

Markus