#1491: mk_language_shell.pl and create_language.pl cause confusion
--------------------+-------------------------------------------------------
Reporter: cotto | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: none | Version: 2.1.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
--------------------+-------------------------------------------------------
Comment(by whiteknight):
I vote for the shared backend code. If people insist, we can have two thin
front-ends which call the shared backend code. The benefit to this kind of
setup is less duplicated logic, easier maintainability, etc. Also, if this
is a tool that we're going to be using and relying on in the long term, we
need to add unit tests and lots of good documentation and examples (and
tests for those examples).
It's probably worth taking some effort to get the design of this tool
correct, especially since this is going to be the first introduction to
Parrot that many developers are going to have, and if it's an absolute
piece of shit a first impression will be created that is going to be hard
for us to overcome later. Plus, this tool is going to create a foundation
for new projects, and problems in this setup will be difficult for people
to correct later.
I suggest the following:
- Merge core logic between the two modules. Add a script with a front-end
that takes a switch. Whichever default we use is inconsequential
- Create two new front-end scripts, create_language and
mk_language_shell, that are thin wrappers around the core utility to force
the switch argument to one value or the other
- Abstract away the generated files and folder structure into some kind
of template file format. That way people will be able to use any existing
template, or create their own. This may be important on certain platforms
where the default setup.pir or makefile might not be correct, or in cases
where certain types of project need different templates. One thing that
comes to mind here is creating extension/embedding applications or shared
bytecode libraries that do not use the same format as a new HLL project,
but for which a template would be very valuable.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1491#comment:9>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
