Parrot's build process and "make install"

Andy Dougherty doughera at
Thu Jul 9 19:57:09 UTC 2009

On Wed, 8 Jul 2009, Patrick R. Michaud wrote:

> At yesterday's #parrotsketch we briefly summarized where things
> are with Parrot's build and install process, and I indicated
> that I'd summarize a list of things to be done and throw a lot 
> of tuits at the problem this week.
> The list of things to be done summary is below.  But in thinking
> about the issues further I've decided that I'm probably not going to be
> able to throw as many tuits at is as I had originally thought, so
> I'm hoping others can step in and pick up the tasks.

I'm afraid I won't be able to help much.  I don't anticipate having
significant free time for parrot for a while.

At first glance, your plan makes sense.  I think this whole affair
needs a top-down approach:  What is it you'd actually like to do?
(e.g. build a dynpmc; run parrot; load in a library, language, or
whatever; etc.).  How should that look?  Then, when it's clear what
information is needed, ensure that generates and stores
that appropriate information.

Every tool in the parrot distribution that has a special --install flag
or if(install) branch is an indication that perhaps didn't
provide the proper information somehow, or that the tool isn't using the
appropriate information.  Every tool that has an C<if($win32)> branch (or
similar) is another such warning indicator.  (See TT #822 for an example).
Of course there are exceptions, but these are indicators worth looking at.

Putting everything into a staging area sounds like a good way to start
tackling this.

    Andy Dougherty		doughera at

More information about the parrot-dev mailing list