replace pdlmaker.plm with independent module

[moocow-the-bovine]

... and specify it in CONFIGURE_REQUIRES

[mohawk2]

Please could you instead just feed whatever needs that meets back into main PDL?

[moocow-the-bovine]

@mohawk2
If and when I get around to this, I'll make an effort to find a flexible enough way to do that, and submit a PR if & when I find something.

As noted in #16 (comment) , I think a a large portion of pdlmaker.plm's reason for existence these days is my own convenience (and requires adherence to my own (unwritten) conventions), so I'm not sure whether it's really generally useful. Thanks for being open to the possibility though.

[moocow-the-bovine]

(copy+pasing this from #16 (comment)) for ease of reference):

I believe you are trying to solve two fairly different problems with one Great Big Solution:

• pure-Perl distros, which really just need the add_doc boilerplate in postamble
• PDL::PP distros, which are well supported by PDL::Core::Dev, with about 3 lines of boilerplate (use, stdargs, postamble)

For both, you can just symlink README.pod to your main module for GitHub purposes. Your pdlmaker.plm would need > to be updated in all your distros when something changes, and it would need to handle all the cases you want to deal > with. That's a lot of effort, and testing it against all the scenarios would be even more.

While comparison can be the thief of joy, MetaCPAN says you have 9 PDL distros. I maintain rather more than that, especially with the recent burst of carving out those no longer belonging in main PDL. I am fanatically lazy, and yet have felt no need to make a Great Big Solution to the above two problems. I'm not telling you how to run your distros, but I am telling you how I run mine.

[moocow-the-bovine]

Your pdlmaker.plm would need to be updated in all your distros when something changes

The idea behind this issue is to eliminate exactly that step (which admittedly is really bad software design, and I can't even claim that I didn't know any better at the time).

[mohawk2]

Based on my experience with various updates to my fleet of distros (albeit more towards CI config), there's no shortcut to having to maintain them as a fleet, especially when some have bespoke needs. Trying to centralise all that stuff with One Ring to Rule Them All would be great cost, minimal benefit.

One approach that I have found beneficial is to make little scriptlets that I run on a list of directories, to e.g. git pull, update bits of config, etc. Then I'd have one to go over all of them doing a git diff to inspect, then one doing make test on all, then commit, then push. Because each required change tends to be unique, it doesn't make sense to systemise it more than that.