Perhaps I am misunderstanding you, but what you have said sounds like a contradiction to me.

You have mentioned the author-only targets (such as make dist) and these can be auto-generated by ExtUtils::MakeMaker but you subsequently say that this module "assumes or imposes that Makefile.PL is for the end-users' benefit only". That is clearly not the case.

Yes, my make dist refered to Autotools' which does creates an end-user, client-side, Makefile. Automatically.

But since you mentioned make dist in the context of ExtUtils::MakeMaker, my question is whether it creates a new Makefile.PL tailored-made for the client-side. AFAIK it just copies verbatim the original Makefile.PL into a dist tarball. Which is not the functionality Autotools provides and I referred to. *Edit*: So nothing contradictory.

my question is whether it creates a new Makefile.PL tailored-made for the client-side.

No, it does not. The same Makefile.PL is (or if you prefer, "can be") used both by the author and by the end-user.

---

🦛

Hello hippo,

maybe I'm confused by the context of this part of the thread (where Autottols has another makefile) but you said:

> author-only targets (such as make dist)

I supposed too this to be true but I'm very disappointed (not by you ;) to discover is not. I'm actually playing with my Makefile.PL to add functionalities only during the author phase (distinct from user phase) and to do this I have overridden dist target (also tried with distdir one).

Actually I have this pattern:

package MY; # so that "SUPER" works right
sub dist {

    # SAVE WHAT RECEIVED BY THE ORIGINAL dist 
        my $inherited = $_[0]->SUPER::dist(@_);    
    
    my $ask_for_git = main::prompt ("*** CUSTOM *** Do you want to spe
+cify a git repository?:"); 

    if ( $ask_for_git =~ /^y/i ){

            ...
[download]

But for what I see the dist target is reached by the cpan client too:

io@COMP:c>cpan .
You are visiting the local directory
  '.'
  without lock, take care that concurrent processes do not do likewise
+.
CPAN: CPAN::SQLite loaded ok (v0.211)
Database was generated on Sun, 24 Jan 2021 14:03:26 GMT
You are visiting the local directory
  'c:/ulisse/games-dice-roller-LazyMakefileOK/Games-Dice-Roller-0.04/G
+ames-Dice-Roller-0.04/.'
  without lock, take care that concurrent processes do not do likewise
+.
  c:/ulisse/games-dice-roller-LazyMakefileOK/Games-Dice-Roller-0.04/Ga
+mes-Dice-Roller-0.04/.
  Has already been unwrapped into directory c:/ulisse/games-dice-rolle
+r-LazyMakefileOK/Games-Dice-Roller-0.04/Games-Dice
-Roller-0.04/.
CPAN: CPAN::Meta::Requirements loaded ok (v2.140)
CPAN: Parse::CPAN::Meta loaded ok (v2.150010)
CPAN: CPAN::Meta loaded ok (v2.150010)
CPAN: Module::CoreList loaded ok (v5.20170114_24)
Configuring c:/ulisse/games-dice-roller-LazyMakefileOK/Games-Dice-Roll
+er-0.04/Games-Dice-Roller-0.04/. with Makefile.PL
CPAN: CPAN::Reporter loaded ok (v1.2018)
Reporting via CPAN::Reporter is disabled for local directories
Name "main::meta_merge_args" used only once: possible typo at Makefile
+.PL line 38.
Checking if your kit is complete...
Warning: the following files are missing in your kit:
        debug.log
        MANIFEST.bak
        pm_to_blib
Please inform the author.
*** CUSTOM *** Do you want to specify a git repository?:

...

  C:\ulisse\perl5.24-64b\c\bin\dmake.exe install UNINST=1 -- OK
[download]

I'd really prefere to use an already present target because of laziness: if I remember to make my_custom_target_do_readme I can also remember to make the readme by hand, no? :)

Both dist and distdir are under ExtUtils::MakeMaker#Distribution-Support where is stated:

> For authors of extensions MakeMaker provides several Makefile targets...

Maybe the cpan client broke the rule? As side note cpan client has no verbose output and I did not found which steps it does to install a module.

Thanks for reading.

L*

There are no rules, there are no thumbs..
Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.