Why do we install .dump files?

Patrick R. Michaud pmichaud at pobox.com
Sun Jun 3 13:09:32 UTC 2012


On Sat, Jun 02, 2012 at 11:07:59PM -0400, James E Keenan wrote:
> When I configure with a prefix, build and install, 95 '.dump' files
> are installed (see
> https://github.com/parrot/parrot/issues/512#issuecomment-5958144).
> Why?

I think that the .dump files are used by downstream users (e.g. HLLs)
as part of building custom dynpmcs; e.g., when subclassing a
Parrot PMC type.  So although Parrot itself doesn't need them
once it is built, the downstream users do.

> All the tests continue to pass.  That implies either (a) the
> installed ./dump files are useless and don't need to be installed;
> or (b) the portion of our current test suite written in Parrot has a
> major deficit in that it fails to test those aspects of Parrot which
> do, somehow, use those .dump files.

Last time I checked, the Parrot test suite does almost no testing
for a successful install, nor does it actually test that an
installed Parrot is able to pass its tests.  In this particular
case, the test you're looking for would probably need to test
using an installed Parrot to build and run a custom dynpmc.
In order for this to work, the .dump files need to be installed, 
as well as all of the header (.h) files, the pmc2c tool, etc.
(Indeed, .dump files are somewhat analogous to .h files for pmc2c,
which is why they're needed.)

I suspect that running "make all_hll_test" on your installed
Parrot would have pointed out the missing .dump files.

It might be worth noting again that AFAIK the Parrot installed 
executables are _never_ tested except via "make all_hll_test".  
What typically happens is that one does "make" and "make test", 
which builds Parrot locally and tests it.  The "make install" 
command then builds an entirely new set of Parrot executables 
(with different internal configuration values) and installs those.  
Thus the installed executables are never tested until a HLL
or some downstream user tries to use them.

To resolve this, perhaps a "make install_tests" target that
runs the Parrot test suite against an installed Parrot (including
tests for downstream user tools such as pmc2c and ops2c, as
mentioned above).  Perhaps "make test" should itself be running
tests against "install versions" of the executables, but this
might be a bit onerous to make happen.

Hope this helps,

Pm


More information about the parrot-dev mailing list