On Sun, Oct 30, 2005 at 09:13:31PM -, Jonathan Worthington wrote:
> One would certainly hope so. :-) I guess this approach can work if the
> code produced by the Perl 5 compiler only contains the subset of Parrot
> functionality that MiniParrot can handle.
The constraint can be pushed high
"Joshua Hoblitt" <[EMAIL PROTECTED]> wrote:
On Tue, Oct 25, 2005 at 11:49:33PM +0100, Jonathan Worthington wrote:
> If people have free time to spend on configure stuff, might it not be
> better spent working on the real configure system that we want to have
> (e.g. a
On Tue, Oct 25, 2005 at 11:49:33PM +0100, Jonathan Worthington wrote:
> If people have free time to spend on configure stuff, might it not be
> better spent working on the real configure system that we want to have
> (e.g. a set of makefiles for each platform to build minipar
On Tue, Oct 25, 2005 at 10:19:50PM +0100, Nicholas Clark wrote:
> On Tue, Oct 25, 2005 at 01:16:27PM -0700, jerry gay wrote:
>
> > i've started developing a plugin architecture for $work, so i've been
> > thinking about plugin engines lately. if you're up for working on a
> > redesign, i'll gladly
On Oct 26, 2005, at 0:49, Jonathan Worthington wrote:
If people have free time to spend on configure stuff, might it not be
better spent working on the real configure system that we want to have
(e.g. a set of makefiles for each platform to build miniparrot, then
configure is a Parrot
one, but *wow* the plugin system for
configuration is grotty. Does anyone have a particular attachment to
it? Would it be useful to clean it up a little bit, or does it need
patching or updating very often?
If people have free time to spend on configure stuff, might it not be better
spent working on the r
On Tue, Oct 25, 2005 at 01:16:27PM -0700, jerry gay wrote:
> i've started developing a plugin architecture for $work, so i've been
> thinking about plugin engines lately. if you're up for working on a
> redesign, i'll gladly pitch in. even if you're looking only to clean
> it up, i'd certainly app
On 10/25/05, chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:
>
> > Minor nit: when running Configure.pl with --nomanicheck, Configure
> > should report the MANIFEST check as "skipped", not "done".
>
> particle beat me to this one, but *wow* the plugin sy
chromatic <[EMAIL PROTECTED]> wrote:
> On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:
>
> > Minor nit: when running Configure.pl with --nomanicheck, Configure
> > should report the MANIFEST check as "skipped", not "done".
>
> particle beat me to this one, but *wow* the plugin system for
> co
On Mon, 2005-10-24 at 17:27 -0700, Will Coleda wrote:
> Minor nit: when running Configure.pl with --nomanicheck, Configure
> should report the MANIFEST check as "skipped", not "done".
particle beat me to this one, but *wow* the plugin system for
configuration is grotty. Does anyone have a part
Bernhard Schmalhofer (via RT) wrote:
I tried to do some cleanup of some makefiles. A patch is attached.
The files config/gen/makefiles/imcc.in and config/gen/makefiles/classes.in
can be removed from CVS.
Thanks, applied.
leo
At 11:53 AM -0500 5/24/02, David M. Lloyd wrote:
>May I be the first to say that the new Configure system *rocks*?
I'll second that. Nice job, Brent.
--
Dan
--"it's like this"-
May I be the first to say that the new Configure system *rocks*?
No more digging through the source code to find that config option...
- D
<[EMAIL PROTECTED]>
Jarkko Hietaniemi wrote:
> The bootstrapping may take several rounds as Parrot learns
...
> - execute (collect output) (note that execution may not be native)
I don't think these two (cross-compile and build-own-tools) are
strictly compatible goals.
If you are going to build your own tools and
On Tue, Sep 11, 2001 at 04:19:12PM +0300, Jarkko Hietaniemi wrote:
> P.S. Maybe the "long term" discussion should take place in
> perl6-build, to draw fire from the "short term"?
Thanks for thinking about this; it'd probably be a good idea to
move to perl6-build.
Simon
(To use Simon's nomenclature)
The long term goal of the Parrot build system (of which configuring is
the major part) is to bootstrap itself from ground zero, a la Parrot
von Münchausen.
Ground zero is here defined as a simple C file (possibly augmented by
one or more simple C headers) and a C co
On Tue, Sep 11, 2001 at 02:49:24AM -0700, Brent Dax wrote:
> Attached are new Configure.pl and config.ht files. Feel free to rename
> config.ht if you want.
I did. Thanks, applied. Now go to sleep. :)
Simon
Simon Cozens:
# On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote:
# > A simple "autogenerate what's already in Parrot's config.h" is easy
#
# This is a good start.
#
# > --I've already written a prototype (pasted after my sig)--but
# > seems like it's too easy considering what you're talk
On Tue, Sep 11, 2001 at 02:22:13AM -0700, Brent Dax wrote:
> A simple "autogenerate what's already in Parrot's config.h" is easy
This is a good start.
> --I've already written a prototype (pasted after my sig)--but
> seems like it's too easy considering what you're talking about. What
> else do
Simon Cozens:
# One of the items on the Parrot TODO is to build a Configure
# system. I don't want to spark up the old metaconfig-versus-autoconf
# debate again, so I'll clarify what I mean.
...
# You'll notice that the Parrot build process currently depends on the
# existence of
One of the items on the Parrot TODO is to build a Configure
system. I don't want to spark up the old metaconfig-versus-autoconf
debate again, so I'll clarify what I mean.
We have long-term and short-term goals for Parrot's configure
system.
The long-term goal is not something I
21 matches
Mail list logo
