On Mon, Sep 06, 2010 at 12:33:12PM -0000, Parrot wrote: > Comment(by jkeenan): > > Replying to [comment:4 gerd]: > > So it should be possible to merge "mk_language_shell.pl" and > > "create_language.pl" and give the result an option to choose the design > > that should be used for the generating of a language. I will start putting > > both scripts together. > > Gerd, Thanks for taking this on. I'm just hoping that we can hear from > Patrick as to his thoughts around ''create_language.pl''.
Sorry it's taken me so long to respond -- I've been trying (and largely failing) to formulate a positive and clear response. Overall I'm -0.5 on the proposal to merge the two scripts into a single tool. As gerd++ points out earlier in the thread, behind the two tools lie strong differences of opinion regarding the mechanics of the build and install system. In fact, the primary reason I abandoned mk_language_shell.pl and started create_language.pl is because I was extremely uncomfortable with the many modifications being made to mk_language_shell.pl, and it was far easier to start again from scratch with a new tool than to try to work around the changes being made to the existing one. At this point I'm still strongly in favor of a build system similar to what create_language.pl, NQP, and Rakudo currently use, and I don't want to feel "encumbered" by setup.pir. I don't find the proposal to provide a "make vs. setup" option switch to create_language.pl to be all that compelling; to a large degree I think it just converts the newbie question of "Which script do I choose, and why?" to "Which --generate-with= option do I choose, and why?". The fact that --generate-with= is proposed to default to "setup" makes me even less happy with the proposed merger, as it basically eliminates the whole reason behind why I started create_language.pl in the first place. The reason my vote is -0.5 instead of a full -1.0 is because I recognize the current situation is not ideal, and I don't have any strong alternatives to offer at this time. I'm also trying to avoid an appearance of "my way of doing things is the only correct answer", because I do acknowledge that there are justifications for the setup.pir approach as well and I respect the efforts the setup.pir authors have put into that system. So, I'm not wanting to say "absolutely don't go down this path". I'm just trying to flag up that I think that trying to develop a single language creation script that supports setup.pir isn't likely to work out at all well for the projects I'm working on, I'm not likely to support the resulting script if it is merged, and that perhaps we could continue searching for other means of resolving the existing confusion. Pm _______________________________________________ parrot-tickets mailing list [email protected] http://lists.parrot.org/mailman/listinfo/parrot-tickets
