* [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged @ 2026-09-26 19:11 Markus Volk 2026-09-29 16:56 ` Alexander Kanavin 0 siblings, 1 reply; 6+ messages in thread From: Markus Volk @ 2026-09-26 19:11 UTC (permalink / raw) To: openembedded-core The Makefile depends on Config.pm and config.h of the staged perl. After pulling an oe-core update that installs perl fresh into the sysroot, these become newer than the Makefile because of a sed in: staging.bbclass:185 cmd = "sed -e 's:^[^/]*/:%s/:g' %s | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:%s:g; ..." Thus make regenerates the Makefile, its asking to be rerun and fails. Clear CONFIGDEP so make ignores those timestamps; a real change of perl reruns do_configure through the task hash anyway. AI-Generated: Uses Claude Code (Claude Opus 5.5) Signed-off-by: Markus Volk <f_l_k@t-online.de> --- meta/classes-recipe/cpan.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes-recipe/cpan.bbclass b/meta/classes-recipe/cpan.bbclass index dbf44da9d2..5b5698fbf8 100644 --- a/meta/classes-recipe/cpan.bbclass +++ b/meta/classes-recipe/cpan.bbclass @@ -58,11 +58,11 @@ do_configure:append:class-nativesdk() { } cpan_do_compile () { - oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}" + oe_runmake PASTHRU_INC="${CFLAGS}" LD="${CCLD}" CONFIGDEP= } cpan_do_install () { - oe_runmake DESTDIR="${D}" install_vendor + oe_runmake DESTDIR="${D}" install_vendor CONFIGDEP= for PERLSCRIPT in `grep -rIEl '#! *${bindir}/perl-native.*/perl' ${D}`; do sed -i -e 's|${bindir}/perl-native.*/perl|/usr/bin/env nativeperl|' $PERLSCRIPT done -- 2.55.0 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged 2026-09-26 19:11 [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged Markus Volk @ 2026-09-29 16:56 ` Alexander Kanavin 2026-09-29 21:54 ` Markus Volk 0 siblings, 1 reply; 6+ messages in thread From: Alexander Kanavin @ 2026-09-29 16:56 UTC (permalink / raw) To: f_l_k; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 886 bytes --] On Sat, 26 Sept 2026 at 21:11, Markus Volk via lists.openembedded.org <f_l_k=t-online.de@lists.openembedded.org> wrote: > The Makefile depends on Config.pm and config.h of the staged > perl. After pulling an oe-core update that installs perl fresh into the > sysroot, these become newer than the Makefile because of a sed in: > staging.bbclass:185 > cmd = "sed -e 's:^[^/]*/:%s/:g' %s | xargs sed -i -e > 's:FIXMESTAGINGDIRTARGET:%s:g; ..." > Thus make regenerates the Makefile, its asking to be rerun and fails. > Clear CONFIGDEP so > make ignores those timestamps; a real change of perl reruns do_configure > through the task > hash anyway. > Thanks, this is a much clearer description of what is happening. But isn't re-generating the makefile actually the correct behavior in this case? Why is it failing? Shouldn't we fix the fail instead of suppressing the regeneration? Alex [-- Attachment #2: Type: text/html, Size: 1482 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged 2026-09-29 16:56 ` Alexander Kanavin @ 2026-09-29 21:54 ` Markus Volk 2026-09-30 11:34 ` Paul Barker 0 siblings, 1 reply; 6+ messages in thread From: Markus Volk @ 2026-09-29 21:54 UTC (permalink / raw) To: Alexander Kanavin; +Cc: openembedded-core [-- Attachment #1: Type: text/plain, Size: 1657 bytes --] 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 [-- Attachment #2: Type: text/html, Size: 2289 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged 2026-09-29 21:54 ` Markus Volk @ 2026-09-30 11:34 ` Paul Barker 2026-09-30 12:10 ` Markus Volk 0 siblings, 1 reply; 6+ messages in thread From: Paul Barker @ 2026-09-30 11:34 UTC (permalink / raw) To: Markus Volk, Alexander Kanavin; +Cc: openembedded-core 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 > <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. 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged 2026-09-30 11:34 ` Paul Barker @ 2026-09-30 12:10 ` Markus Volk 2026-09-30 14:32 ` Paul Barker 0 siblings, 1 reply; 6+ messages in thread From: Markus Volk @ 2026-09-30 12:10 UTC (permalink / raw) To: Paul Barker; +Cc: Alexander Kanavin, openembedded-core [-- Attachment #1: Type: text/plain, Size: 3764 bytes --] 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 <paul@pbarker.dev> 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 >> <alex.kanavin@gmail.com <mailto: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. > > 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 (#246959): > <https://lists.openembedded.org/g/openembedded-core/message/246959> > Mute This Topic: <https://lists.openembedded.org/mt/121446692/3618223> > Group Owner: openembedded-core+owner@lists.openembedded.org > <mailto:openembedded-core+owner@lists.openembedded.org> > Unsubscribe: > <https://lists.openembedded.org/g/openembedded-core/unsub> > [f_l_k@t-online.de <mailto:f_l_k@t-online.de>] > -=-=-=-=-=-=-=-=-=-=-=- > [-- Attachment #2: Type: text/html, Size: 4315 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged 2026-09-30 12:10 ` Markus Volk @ 2026-09-30 14:32 ` Paul Barker 0 siblings, 0 replies; 6+ messages in thread From: Paul Barker @ 2026-09-30 14:32 UTC (permalink / raw) To: Markus Volk; +Cc: Alexander Kanavin, openembedded-core On Wed, 2026-09-30 at 14:10 +0200, Markus Volk wrote: > 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.” Hi Markus, I am struggling to follow what the actual issue is here. The commit message in the v2 patch said "these become newer than the Makefile because of a sed in: staging.bbclass:185". This is why I recommended changing that to preserve mtime. If the issue isn't that sed call, then we need to find the actual root cause. Best regards, -- Paul Barker ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-09-30 14:32 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-09-26 19:11 [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged Markus Volk 2026-09-29 16:56 ` Alexander Kanavin 2026-09-29 21:54 ` Markus Volk 2026-09-30 11:34 ` Paul Barker 2026-09-30 12:10 ` Markus Volk 2026-09-30 14:32 ` Paul Barker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.