[oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[Markus Volk]

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

Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[Alexander Kanavin]

[-- 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 --]

Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[Markus Volk]

[-- 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 --]

Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[Paul Barker]

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

Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[Markus Volk]

[-- 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 --]

Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged

[Paul Barker]

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