On Tue, Sep 29 2026 at 18:56:26 +02:00:00, Alexander Kanavin
<[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246902):
https://lists.openembedded.org/g/openembedded-core/message/246902
Mute This Topic: https://lists.openembedded.org/mt/121446692/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
