RFC: Move build tools to Perl5, developer tools to Perl6

Will Coleda will at coleda.com
Fri Feb 15 15:26:42 UTC 2013

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 nqp).

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:

> Howdy.
> 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 ideal
> situation.
> I propose moving build tools to Perl5 and developer tools to Perl6,
> where a build tool is a program that gets run when an end-user checks
> out the codebase and wants to install Rakudo, whereas a developer tool
> only needs to be run after changes to the codebase have been made.
> 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 development
> process as well (a P6 ops2c would need to be run after dynop changes
> instead of as a part of regular builds), but I believe the benefits
> would be worth this hopefully minor inconvenience (dynops change
> 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 not
> aware of any policy governing the stability of NQP, and the migration
> from NQP-rx to NQP would be a case in point.
> Thoughts?
> -- gerdr
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev

Will "Coke" Coleda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20130215/16146e84/attachment.html>

More information about the parrot-dev mailing list