Parrot's build process and "make install"

Andy Dougherty doughera at lafayette.edu
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 Configure.pl 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 Configure.pl 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 lafayette.edu


More information about the parrot-dev mailing list