On 11/21/18 10:49 PM, Konstantin S. Uvarin wrote:
Oh, so Makefile.PL is capable of recursion. I should've checked it first.
But! I couldn't bring it to `make dist` recursively; instead, it just lumps
all the directories into a huge tarball. Is that OK for CPAN?
My first idea, demonstrated by make-bundle.sh, was to put the
distribution source trees inside the collection source tree for
development purposes. When everything is good, each distribution would
get its own tarball and the top-level collection would get its own
tarball without the nested stuff (the way make-bundle.sh works today).
But, perhaps a flat directory layout would be better -- e.g. the
collection and distribution source trees all rooted in the same
directory. Then it becomes a question of finding or reworking the tools
to understand relationships and recursion traversal order.
Or should I really upload separate tarballs for each module?
If the collection and all of the distributions track head revisions,
that would be the conventional approach. But, I have read about putting
specific versions of modules and/or distributions into collection
distributions due to forward compatibility, platform support, and/or
other concerns.
Or is there a way to tweak Makefile.PL into recursing for make dist, too?
I spent some time reading the ExtUtils::MakeMaker, ExtUtils::MM_Unix,
and ExtUtils::MM_Any source files, and experimenting with the Makefile
generated by make-bundle.sh.
The top-level Makefile appears to implement recursion for 'make' and
'make test' explicitly via prerequisites:
307 all :: pure_all manifypods
308 $(NOECHO) $(NOOP)
309
310
311 pure_all :: config pm_to_blib subdirs linkext
312 $(NOECHO) $(NOOP)
313
314 subdirs :: $(MYEXTLIB)
315 $(NOECHO) $(NOOP)
434 subdirs ::
435 $(NOECHO) cd DistA && $(MAKE) $(USEMAKEFILE)
$(FIRST_MAKEFILE) all $(PASTHRU)
808 test :: $(TEST_TYPE) subdirs-test
809
810 subdirs-test ::
811 $(NOECHO) $(NOOP)
812
813 subdirs-test ::
814 $(NOECHO) cd DistA && $(MAKE) test $(PASTHRU)
For the target 'pure_all', if I put the prerequisite 'subdirs' first,
then 'make' will build DistA before Bundle::MyBundle:
2018-11-22 23:48:41 dpchrist@tinkywinky ~/sandbox/perl
$ bash make-bundle.sh 2&>1 > /dev/null
2018-11-22 23:48:45 dpchrist@tinkywinky ~/sandbox/perl
$ cd make-bundle.sh.tmp/Bundle-MyBundle/
2018-11-22 23:48:54 dpchrist@tinkywinky
~/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle
$ cp Makefile Makefile-orig
2018-11-22 23:49:04 dpchrist@tinkywinky
~/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle
$ vi Makefile
2018-11-22 23:49:25 dpchrist@tinkywinky
~/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle
$ diff Makefile-orig Makefile
311c311
< pure_all :: config pm_to_blib subdirs linkext
---
> pure_all :: subdirs config pm_to_blib linkext
2018-11-22 23:49:31 dpchrist@tinkywinky
~/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle
$ make
make[1]: Entering directory
'/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA'
Manifying 1 pod document
make[1]: Leaving directory
'/home/dpchrist/sandbox/perl/make-bundle.sh.tmp/Bundle-MyBundle/DistA'
Skip blib/lib/Bundle/MyBundle.pm (unchanged)
Manifying 1 pod document
Similarly so for the target 'test'.
The target 'dist' does not include a target for DistA (subdirs-dist),
which explains the lack of recursion.
I have written MY overrides in the past, and could probably do so for
the targets I am interested in:
https://metacpan.org/pod/ExtUtils::MakeMaker#Overriding-MakeMaker-Methods
But somewhere in my reading, I saw a statement that the EUMM team is
trying to get away from overrides and instead implement data-driven
solutions. I interpret this to mean revising EUMM and related so that I
can achieve the above results via arguments to WriteMakefile() in
Makefile.PL:
recurse_order => 'depth-first',
recurse_target_dist => 1,
recurse_target_disttest => 1,
with built-ins:
recurse_Makefile_PL => 1,
recurse_target_all => 1,
recurse_target_test => 1,
Implementing such a solution would be non-trivial for me.
Then, there's Module::Build, Dist::Zilla, CPAN, CPAN Testers, and likely
many more tools and systems I am oblivious to. The above proposals
would need to be consider for each of them.
David
