RFC: Move build tools to Perl5, developer tools to Perl6
gp at zimt.uni-siegen.de
Thu Feb 21 06:25:59 UTC 2013
If parrot should be trimmed down and pge and tge should removed than
the file runtime/parrot/library/Tcl/Glob.pir is the first that has to
It is the last thing in a chain that depend on PGE. Should it be
rewritten with parrot-nqp or with the HLL API?
Am Freitag, den 15.02.2013, 10:26 -0500 schrieb Will Coleda:
> My plans for the sixparrot branch currently include: switching build
> steps that rely on parrot-nqp and winxed back to their original perl5
> scripts (if possible), and removing pge, tge, and parrot-nqp.
> It's possible I may end up keeping winxed, but killing parrot-nqp is
> definitely on the list (and I don't intend to replace it with current
> I'm not sure what dev tools you're referring to. NQP isn't using much
> of anything once parrot itself is built that isn't already used by
> parrot. (e.g. ops2c); I still plan on supporting conversion of .ops
> to .c without having to have anything other than current parrot deps
> installed (e.g. perl5 is fair game, but not perl6).
> On Fri, Feb 15, 2013 at 6:45 AM, Gerhard R.
> <gerd.r.devel at googlemail.com> wrote:
> Right now, the toolchain is written in a mix of Perl5, PIR,
> NQP and
> Winxed. I don't think I need to elaborate why this is not an
> I propose moving build tools to Perl5 and developer tools to
> where a build tool is a program that gets run when an end-user
> out the codebase and wants to install Rakudo, whereas a
> developer tool
> only needs to be run after changes to the codebase have been
> The most immediate concern would be ops2c. It is run during
> the build
> process to parse dynop definitions and according to policy the
> old P5
> implementation should be resurrected.
> However, I don't see a problem with moving it to the dev tools
> category and porting the NQP-rx codebase to P6: Right now, the
> generated files for core ops are checked-in, and I believe
> this could
> be done for dynops as well.
> Rakudo devs should weigh in here as it would affect their
> process as well (a P6 ops2c would need to be run after dynop
> instead of as a part of regular builds), but I believe the
> would be worth this hopefully minor inconvenience (dynops
> rarely, correct?).
> So why choose P6 instead of NQP as the implementation language
> for dev
> tools? Because NQP is not the user-facing product - P6 is. I'm
> aware of any policy governing the stability of NQP, and the
> from NQP-rx to NQP would be a case in point.
> -- gerdr
> Will "Coke" Coleda
More information about the parrot-dev