http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec
http://ftp.kspei.com/pub/steve/rpms/parrot-0.4.9-1.src.rpm
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: st...@kspei.com http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
Thanks, Steve. Have you kept a list of the things that are difficult
about the process? Making it easy to package up Parrot for .rpm, .deb,
etc, is definitely one of our goals.
Allison
> Steven Pritchard wrote:
My theory: the "all Parrot developers work from within the tree, so
installation paths are either not present or wrong" problem is a big problem.
-- c
Agreed. And we don't work from the installation paths because the
installation paths are broken. Can we break out of this cycle with some
automated tests for the installed Parrot?
Allison
That would be pretty slick. :-)
I didn't keep a list, but I do have the spec. Quickly glancing at it,
I see three things that I would classify as problems:
1) "lib" is hard-coded in a few places. (On x86_64 Fedora and other
RH derivatives, the system library path is /lib64 and /usr/lib64.)
I hack around that in %prep with this:
%{__perl} -pi -e 's,"lib/,"%{_lib}/, if (/CONST_STRING\(interp,/)' \
src/library.c
%{__perl} -pi -e "s,'/usr/lib','%{_libdir}',;s,runtime/lib/,runtime/%{_lib}/," \
tools/dev/install_files.pl \
tools/dev/mk_manifests.pl
Ideally, the install scripts should allow for installing
non-architecture-specific bits in /usr/share and the
architecture-specific binary bits in /usr/lib64.
2) The last time I checked, to get everything to work right I had to
set LD_LIBRARY_PATH to $topdir/blib/lib.
3) The languages/ stuff isn't installed automatically. I'm not even
sure where it should go.
The rest is all minor cleanup and sub-optimal (for my purposes)
defaults. If you look through the spec, it should all be pretty
obvious...
I have already suggested in a previous mail "the value of a install target"
the goal of making the working copy and the install target exercise the
loader in the same way.
The reason I chose the language: "exercise the loader" was to dodge this testing
bullet.
Expanding the test-suite to cover the install target is alot of work, and
an unpleasant administrative burden to remind and cajole the developers into
passing the install tests; which they may not even care about.
If it was built in a traditional way the test-suite would also have to
be extended as the project grew with coverage testing, it's a vicious cycle :)
The answer is to make a guarantee of a flat search space for modules.
Authors can insert into that search space foo.pir or myproject/foo.pir.
This flat search space needs to be assembled in the *working-copy* and
in the install tree.
In fact parrot does this already !
here is a snip from src/library.c:90
<snip>
entry = CONST_STRING(interp, "runtime/parrot/library/");
VTABLE_push_string(interp, paths, entry);
</snip>
and from src/library.c:94
<snip>
entry = CONST_STRING(interp, "lib/parrot/library/");
VTABLE_push_string(interp, paths, entry);
</snip>
This hack is built-in for the runtime core. What is really missing is a
comprehensive design that de-couples policy (where things go) from
hand-editing source files.
Once this table in library.c is generated from a policy spec, that policy
can either describe what the install should be, _and_ what the working-copy is.
Ideally an author should be able to create
project/main.pir
project/foo/bar/install.spec
project/foo/bar/bar.pbc
project/foo/bar/mystuff/util.pbc
and in main.pir do this:
.load_bytecode "bar"
.load_bytecode "mystuff/util"
and this would work because install.spec ( name doesn't matter at this point )
has specified that the files and directories below are relative to the flat
search space.
Note that ideally the author would simply setup such a install.spec file at the
beginning, update parrot with the new policy, and at that point ignore the
file except occasionally adding/removing pieces to install. Once the path has
been added to the search path list it is a true member of the unified name-space.
With this scheme the testing is focused on a single point: the loader. The loader
is significantly enhanced with powerful features integrated into a comprehensive
design. Once that basket is well-built things either load or they don't , irrespective
of whether it is installed or not.
In short this will make things work, because things will break for developers as they
would for users, a isomorphic mapping that sidesteps non-linear growth in the test-suite.
The key is the design, which unfortunately I don't have the time to put out in this mail.
I have it in my head, and I will sketch it out in a diagram.
If someone could point me at a suitable related wiki, or other hosting location where I could
upload a .png diagram, and some text describing the design I have developed I should be able
to assemble this sometime within the next week or two.
Cheers,
Mike Mattie (coder...@gmail.com)
> If someone could point me at a suitable related wiki, or other hosting location where I could
> upload a .png diagram, and some text describing the design I have developed I should be able
> to assemble this sometime within the next week or two.
The Parrot wiki is probably the place to put it:
http://rakudo.org/parrot/index.cgi?parrot
Paul
> This hack is built-in for the runtime core. What is really missing is a
> comprehensive design that de-couples policy (where things go) from
> hand-editing source files.
Last October or November, I posted a PIR snippet that demonstrated how to
modify the interpreter's search paths at runtime. I don't have time to find
the code now, but it's doable from PIR.
That could become a library similar to lib.pm in Perl 5.
-- c
> On Wed, 21 Mar 2007 18:39:51 -0700
> Allison Randal <all...@perl.org> wrote:
>
>> chromatic wrote:
>>
>> Agreed. And we don't work from the installation paths because the
>> installation paths are broken. Can we break out of this cycle with
>> some automated tests for the installed Parrot?
>>
>> Allison
>
> I have already suggested in a previous mail "the value of a install
> target"
> the goal of making the working copy and the install target exercise the
> loader in the same way.
>
> The reason I chose the language: "exercise the loader" was to dodge
> this testing
> bullet.
Actually, I don't believe that it would be that difficult. All that
should need to happen is change which parrot is ran. A
"test_installed" target that isn't dependent on building
parrot(confusing, but think of how the Makefile works) that runs the
installed parrot, and using the local perl modules should suffice. I
imagine it'd be one of the easier parts of a complete installed parrot.