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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
