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