extra .pmc files in src/pmc cause silent pbc compatibility breaks

[cotto]

In TT #823, Coke experienced some mysterious test failures because he had a stray .pmc file in src/pmc. This PMC was silently built into Parrot even though it wasn't in MANIFEST and didn't belong.

A solution to this behavior is to have the generated Makefile explicitly list all PMCs rather than using the suffix rules (see config/gen/makefiles/root.in +655). Alternately, a big noisy warning when there are PMCs not listed in MANIFEST would be sufficient. The idea is that it should be hard for a user or developer to unknowingly build Parrot with extra PMCs

[jkeenan]

Replying to cotto:

I started to look into this issue this weekend and committed some updates to config/auto/pmc.pm and its associated test file which may help to clear away the underbrush impeding a solution.

My hunch is that the problem is rooted in the fact that the only quasi-canonical list of PMCs apart from MANIFEST is found in src/pmc/pmc.num. That file provides a mapping of PMCs to incremental sequence numbers (but also includes mappings for long-since-deleted PMCs. If you call touch src/pmc/myphony.pmc, you will vary quickly get uninitialized value warnings and outright failures during perl Configure.pl. But I suspect that if have a well-formed PMC file there which is listed neither in src/pmc/pmc.num nor MANIFEST, it could sneak into a Parrot build.

kid51

[jkeenan]

Replying to cotto:

Alternately, a big noisy warning when there are PMCs not listed in MANIFEST would be sufficient. The idea is that it should be hard for a user or developer to unknowingly build Parrot with extra PMCs

cotto,

Can you review r48598? It should provide the warnings you suggested.

Thank you very much.

kid51

[cotto]

kin51, thanks for adding this. An extraneous PMC added before configure-time will cause a noisy (though non-fatal) warning and a PMC added will be properly ignored. I'll mark this fixed.