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

Jonathan "Duke" Leto jonathan at leto.net
Thu Feb 21 22:26:26 UTC 2013


Howdy,


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

Since the current Parrot frontend uses Winxed [0], that seems a bit
overkill. I have no problems with removing our elderly and bitrotten fork
of nqp, but I consider Winxed as one of the shinier parts of Parrot and
would be very -1 to seeing it leave core.

Duke

[0] frontend/parrot2/prt0.winxed



> 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
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>


-- 
Jonathan "Duke" Leto <jonathan at leto.net>
Leto Labs LLC http://labs.leto.net
209.691.DUKE http://dukeleto.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20130221/ab259260/attachment.html>


More information about the parrot-dev mailing list