Why do we install .dump files?

James E Keenan jkeen at verizon.net
Mon Jun 4 02:14:06 UTC 2012


Patrick's and Allison's responses raised a number of points about 
multiple issues.  Let me try to distinguish among them:

I. Scope of Parrot's Test Suite

On 6/3/12 9:09 AM, Patrick R. Michaud wrote:
>
> 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.

Agreed, but in my experience that's a limitation Parrot shares with a 
lot of software.  With Perl 5, for instance, I've done the 
Configure-make-make test-make install cycle many times, but never have 
rerun the test suite with the installed Parrot.

> 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.)
>

Can someone open a bug ticket for this?


II. 'make install' installs different executables from those which were 
tested.

> [snip]
> 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).
>

Another possible subject for a bug ticket.  In fact, didn't we deal with 
this issue at some point in the past.

> Perhaps "make test" should itself be running
> tests against "install versions" of the executables, but this
> might be a bit onerous to make happen.
>

Yes, I think that would be a bit much for 'make test'.

III. 'make install' versus 'make install-dev'

On 6/3/12 9:08 AM, Allison Randal wrote:
 >
 > They're required for building PMCs that inherit from Parrot core PMCs.
 > They were only supposed to be installed with make install-dev, but then
 > someone changed the default install to pull in install-dev.
 >

Should we revert this?  If so, what should be the criteria to determine 
what goes into install-dev only?  Should those criteria parallel those 
which, for instance, a Debian packager might make between a regular and 
a -dev package?

 > We don't install all the .dump files, only the ones that certain
 > languages needed to build. They aren't needed at all for running Parrot,
 > only for building a language.
 >
 > One possible solution is to stop using .dump files in the PMC build
 > process. It's one of the ugliest parts of the build process.
 >

I agree.  In the spirit of Issue #512 (and its Trac predecessor), I've 
periodically taken stabs at trying to replace Storable with JSON, but 
without success.  I can think of a number of questions that need to be 
answered:

1. What would it take to replace Storable with JSON?

2. Even if we did replace Storable with JSON, we'd still have a build 
process dependent on dump files.  Can we do better?

3. Most importantly, this is a point where we really need to get the 
input of HLL-designers and the developers of other projects built on top 
of Parrot (Winxed? Rosella?).  What do *they* need (or what do some of 
*us* need in our non-Parrot-core-developer roles)?  Is what they need 
different from what the Parrot build process needs?

Thank you very much.
Jim Keenan



More information about the parrot-dev mailing list