Manification is not parallelizable

[Leont]

Currently, manpages are always generated in a single action: manifypods. This means not only that pod2man has to redo some of make's file-changed checking, but also that the manification can not be parallellized.

I can imagine the current behavior being favorable on Windows (because starting new processes is rather expensive there, but for Unix this is rather unhelpful.

[dolmen]

There is no point in generating manpages on Windows (at least pure MSWin32, not cygwin) as we don't have tools to read them, so a pure Unix solution should be fine.

[Leont]

There is no point in generating manpages on Windows (at least pure MSWin32, not cygwin) as we don't have tools to read them, so a pure Unix solution should be fine.

Right, that's a good point.

Actually, pm_to_blib has a similar issue, though I suspect the performance benefit there would be more limited.

[Leont]

Great, the naive solution doesn't appear to work, because manpages typically have colons in their name, and make doesn't support that in target names.

[mohawk2]

My experiments with GNU make suggests that using \: works to quote colons. Did you try that?

[mohawk2]

Also, my reading of BSD make man pages (thanks) indicates they also understand quoting of : with \.

[mohawk2]

Once PR #130 is merged, a simple use of (and update to) the quote_dep method should make this easy. @Leont, could you possibly let me have the code of your naive solution to make this even easier to fix, maybe paste it in a comment here?

[Leont]

I can't find it anymore :-(

[mohawk2]

No problem. Once the PR is in, I'll sort this.

[mohawk2]

Apparently I didn't yet. However, it seems to me that this issue plus #111 are an opportunity to think about an extension mechanism for EUMM beyond the "MY" thing. The main requirement would be that more than one could be installed for a given target, without getting in each other's way. For a doc-generating engine we would have an HTML one, a man-page one, and possibly others.