Branch: refs/heads/bram/touch_miniperl_to_rebuild_everything
  Home:   https://github.com/Perl/perl5
  Commit: a6eeff7c6718cb80b60e464963876437fcd8356d
      
https://github.com/Perl/perl5/commit/a6eeff7c6718cb80b60e464963876437fcd8356d
  Author: Bram <perl...@wizbit.be>
  Date:   2022-04-10 (Sun, 10 Apr 2022)

  Changed paths:
    M Makefile.SH

  Log Message:
  -----------
  Makefile.SH - touch miniperl to ensure its dependencies are built

In short there is an insiduous relationship between buildcustomize.pl
and miniperl in our makefiles. This relationship means miniperl depends
on buildcustomize.pl even though buildcustomize.pl requires miniperl to
be built. There is a comment explaining this is intentional and
simplifies things (although it does not say what it simplifies).

What this means is that the lib/buildcustomize.pl target:
- creates miniperl
- uses miniperl to create 'lib/buildcustomize.pl'

Combined with the miniperl target not having any actions, just a
dependency declaration on lib/buildcustomize.pl seems to cause GNU make
(at least) to not restat the rebuilt miniperl.

This then means that various other targets which depend on miniperl do
not see the rebuilt miniperl and are not rebuilt themselves. Examples
include pod/perlintern.pod and autodoc.pl.

Thus to completely build everything you need to run make *twice*.
Normally the recipe is "make" and then "make test", which means make
gets run twice. But when developing or bisecting make is not normally
run twice, this can result in files not being rebuilt and which can lead
to errors being overlooked.

The solution appears to be to touch the miniperl executable as part of
the miniperl target, which then causes make to notice that the mtime of
the file has changed and rebuild the things that depend on it.

See

https://www.nntp.perl.org/group/perl.perl5.porters/2022/04/msg263517.html

for much more details.

Note this commit message was written by the committer (Yves) and not the
author of the patch and the post above (Bram). Any mistakes it contains
are not Bram's fault.


Reply via email to