Hi Paul,
I think this is generally a good idea and I can create a patch for it.
But presumably this will not fix my problem:
Something in the signature of perl-native changes, such as a class, a
variable, or a native dependency, without the result changing.
The taskhash changes; there is no sstate for it, so perl-native is
rebuilt. After the build, bitbake reports the outhash to the hash
server.
The output is identical to the previous one, so the server maps the new
taskhash to the old unihash.
The tasks in libio-socket-ssl-perl construct their hashes from the
unihashes of their dependencies. For them, nothing has changed:
`do_configure` does not run again, and the old Makefile remains.
However, the consumer’s sysroot remembers the dependency’s
taskhash, not the unihash. It sees the new taskhash, removes
perl-native,
and restages it. The files come from the fresh build and carry its
timestamp. Afterward, sed -i sets them to “now.”
On Wed, Sep 30 2026 at 12:34:29 +01:00:00, Paul Barker
<[email protected]> wrote:
On Tue, 2026-09-29 at 23:54 +0200, Markus Volk wrote:
On Tue, Sep 29 2026 at 18:56:26 +02:00:00, Alexander Kanavin
<[email protected] <mailto:[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.
Hi Markus,
There is another possible approach here. We could modify
staging_processfixme() to preserve the mtime of the files it modifies.
That should prevent cpan Makefiles from being considered out-of-date
when perl is re-staged.
Thanks,
--
Paul Barker
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#246962):
https://lists.openembedded.org/g/openembedded-core/message/246962
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]]
-=-=-=-=-=-=-=-=-=-=-=-
