Thanks, Mike, and welcome to the bird house. :)
Mike Mattie wrote:
In short parrot needs work on the install target, and I need to
justify the value of the target to the project before proposing any
changes.
The install process is generally known to need work, and critical to the
1.0 release, so we welcome your patches and suggestions.
> -> 2. My use case
> -> 3. Value of a install target
Agreed that the average users (i.e. the greatest number of people using
Parrot) are not the compiler writers, but the language users, and on the
importance of a working install target. So, I'll skip down to:
I looked at several of the languages in the parrot tree and saw alot
of test-harness like stuff. When I went to run pheme with: (+ 1 1)
I found pheme broken completely with:
Couldn't find file 'compilers/tge/TGE/Rule.pbc'
Part of this problem is that Parrot doesn't currently have the
equivalent of @INC or 'use lib'. We shouldn't be specifying a literal
file path to a module here, but a simple name, and have Parrot search a
(modifiable) list of directories.
What is a reasonable expectation ?
I think that if a parrot hacker gets up and does a slide-show with the
highlights of parrot, that viewers should be able to install parrot
using their distro, and then run the examples given.
Instead of trying to untangle the impossible problem of an API/ABI
re-formulate the problem in this way:
"what cool features do we want to show off"
That's a good fundamental goal.
-> 3.2 requirements of a parrot install target.
1. install all of the necessary files into the install image.
Parrot is badly broken here. below is a list of files I added in my
install image via ebuild (gentoo build system)
Some of these files are obviously experiments like STM.pbc but
things like PGE/{Text,Util}.pbc are used all over the place.
A distro packager does not know the difference between experiments
and dependencies without investing in the knowledge of a parrot
contributer.
I expect that some files will be included in the "core" install image,
and others will be loaded as separate packages. Looking over your list,
I agree that most of those modules are necessary to doing anything
useful with Parrot, and so should be included in the core. Most (perhaps
all) languages/ won't be, so I'd have to run something like (debian
example):
$ aptitude install parrot-python
to get the python language implementation on Parrot.
(Note that this means anyone can release their own language
implementation for Parrot as a separate package, without getting it
added to the core.)
What we need is better meta-information for the install process and
package builders on what is and isn't necessary for a core install. And,
a strategy for installing extras in the basic install process.
2. equivalent behavior when running in a install tree, and a build tree.
The paths requested by higher-level components are broken, ie:
hard-coded to the layout of the check-out tree. lots of
load_bytecode/include foo.{pir,pasm,pbc}.
I'm happy enough with this, but it does assume that all the .pir, .pasm,
or .pbc files are stored in the same directory (there's been some debate
about that, and about the corresponding .tg and .pg files).
directory components in paths is a bit more tricky. The loader needs
to be exercised in the same way in both the install-tree and the
build-tree. I have a proposal for this in development, but it is a
little bit more invasive than getting rid of hard-coded extensions.
Agreed, and connect to earlier comments about @INC/'use lib'.
3. install targets/lists for the languages.
[...]
3.1. where do languages go ?
This is a distro issue, I will ponder more on it , but ignore it for now.
Yeah, the exact directory structure isn't critical, but figuring out how
to handle varying directory structures for various distros is
(configurable search paths again).
3.2. What to install ?
This is the showstopper. that find command is hideous. I don't even
need an actual install target that each language maintains. At
this point a flat-file with one-per-line listing of the runtime files
would be just fine.
The big thing to notice here is that I am not talking about breaking
the languages out of the tree. I think that would greatly harm the
parrot project. It is sufficient to have a make target for building,
and a list of files to install, or another make target for installing
if that is deemed necessary.
I suspect languages will need to each have their own install target,
with the appropriate information about which files need to be installed.
Especially when we get into languages that aren't part of the Parrot
repository. And being able to ship a language separate from the whole
Parrot install is an important goal, in much the same way that you can
ship a tool that expects a C compiler without including the C compiler
in your tarball.
It may be that we can handle this with a simple YAML file in each
languages/ directory.
Only make build targets and install lists are minimally necessary.
Languages should remain in-tree. Adding a source/built-object to
the install list should be data-driven and dead simple for language
hackers (per-language MANIFEST ?)
MANIFEST is also possible, though it usually indicates which files are
necessary to build, not which files should be installed (e.g. it
includes all the tests and source files, which won't be installed).
Parrot,languages, and apps need to behave the same in both the
install tree, and the build-tree.
Absolutely. We can't entirely get around the fact that they are
different environments (for example, the install will be lacking a
number of files only needed for the build process), but we can minimize
the differences as much as possible.
We might setup a framework for running tests against the installed
Parrot too (not for general users to run, but for maintainers to run).
I am working [ spare-time ] on a gentoo ebuild (un-official , I am
_not_ a gentoo dev ), and I am also working up a couple of proposals
for deltas to the parrot tree addressing some of the issues that I
have raised.
Thanks for the thorough and carefully considered analysis of the
problem. I look forward to reviewing the specific change
proposals/suggestions that grow out of it.
Allison
