All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Barker <paul@pbarker.dev>
To: Markus Volk <f_l_k@t-online.de>,
	Alexander Kanavin <alex.kanavin@gmail.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [oe-core][PATCHv2] cpan: do not rebuild the Makefile when perls config is re-staged
Date: Wed, 30 Sep 2026 12:34:29 +0100	[thread overview]
Message-ID: <f463545abd207af98291ac45019a6f263ca4da20.camel@pbarker.dev> (raw)
In-Reply-To: <GJB5MT.IT6MLUSWWCCS3@t-online.de>

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



  reply	other threads:[~2026-09-30 11:34 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2026-09-30 12:10       ` Markus Volk
2026-09-30 14:32         ` Paul Barker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f463545abd207af98291ac45019a6f263ca4da20.camel@pbarker.dev \
    --to=paul@pbarker.dev \
    --cc=alex.kanavin@gmail.com \
    --cc=f_l_k@t-online.de \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.