[perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc

[Patrick R . Michaud]

# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #47992]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47992 >


I just recently committed examples/sdl/blue_rect.pl as an
example of exercising the SDL library using NQP. At the
beginning of the file the instructions read:

To run this file, execute the following command from
the Parrot directory:

$ ./parrot compilers/nqp/nqp.pbc examples/sdl/blue_rect.pl

Typing in that pathname is a bit of a pain -- what I'd really
like to be able to say is

$ ./parrot nqp examples/sdl/blue_rect.pl

and then since parrot can't immediately find anything called
'nqp' to execute, it looks for nqp.pbc in a standard location
or locations and invokes that. Similarly

$ ./parrot perl6 blue_rect.pl
$ ./parrot tgc --output=gen.pir PASTGrammar.tg
$ ./parrot abc
$ ./parrot tcl xyz.tcl
$ ./parrot pynie hello.py
etc.

Before we get too far, let me point out what I'm *not* asking for.
Specifically, I'm *not* asking for parrot to automatically select
an appropriate compiler based on a file's signature or magic, as
discussed in RT#32374. In other words, I'm *not* asking that

$ ./parrot examples/sdl/blue_rect.pl

be able to automatically determine an appropriate compiler
and invoke it on the script. While this is a very worthy and
important goal, at the moment there seem to be so many issues
around "how does Parrot register compilers and figure out which
one to use" that I fear it will be a while before this gets
implemented. I want something sooner than that.

I'm also explicitly *not* asking to try to handle or resolve
things based on Unix shebang lines, so that a file starting with

#!/path/to/parrot nqp

will automatically be executed with nqp. Again, it's something
we will eventually want to consider, but given the vagaries
of dealing with shebangs in so many different languages and
platforms it's not what I'm aiming to get from this ticket.

All I'm really looking is to be able to place the .pbc file for
a compiler or other application into a standard location where it
can be invoked from Parrot without having to give a complete
path to the .pbc file.

This could also have the benefit of simplifying Makefiles as well.
For example, when I moved nqp from languages/ to compilers/ , I had
to change the Makefile from

$(PARROT) $(PARROT)/languages/nqp/nqp.pbc ....

to

$(PARROT) $(PARROT)/compilers/nqp/nqp.pbc ...

While it was easy to do for this one case -- imagine if we had
10 or 20 applications that were using nqp as part of the
build process. With the approach proposed here, the Makefile
can have

$(PARROT) nqp ...

and it all just works.

I would also be willing to accept an option-based version of
this, such as (pick an appropriate option name or letter):

$ ./parrot --prog=nqp blue_rect.pl


Comments, suggestions, and (most importantly) implementations welcomed.
Thanks,

Pm

[Patrick R. Michaud]

As mentioned in RT #49168, I'm in favor of a --language flag,
that selects the default PBC/PIR file to run, and passes all other
arguments to the ':main' sub in that file. It can also select default
paths based on the options set the the configuration file for that language.

Agreed on the --language concept, although I think I prefer "--prog"
(mentioned in #49168) to "--language". Not everything we might want
to invoke in this manner is actually a compiler or language.

If we're agreed on this approach, I'll open a [todo] ticket for it.
I might even write the patch to make it work. :-)

Pm

[Patrick R. Michaud]

As mentioned in RT #49168, I'm in favor of a --language flag,
that selects the default PBC/PIR file to run, and passes all other
arguments to the ':main' sub in that file. It can also select

default

paths based on the options set the the configuration file for that

language.
Agreed on the --language concept, although I think I prefer "--prog"
(mentioned in #49168) to "--language". Not everything we might want
to invoke in this manner is actually a compiler or language.
If we're agreed on this approach, I'll open a [todo] ticket for it.
I might even write the patch to make it work. :-)
Pm

Do the fakecutables satisfy the spirit of this request?

IMO, not really. I don't think we want to treat fakecutables as
the official mechanism for creating command-line tools using Parrot.

Pm

[Allison Randal via RT]

As mentioned in RT #49168, I'm in favor of a --language flag, that selects the default
PBC/PIR file to run, and passes all other arguments to the ':main' sub in that file. It can also
select default paths based on the options set the the configuration file for that language.

Then, using the $0 argument to 'main' in src/main.c, we can treat the name of the
executable as setting the --language option, so, if 'perl6' is an alias to 'parrot', then:

$ perl6 myfile.pl

is the same as:

$ parrot --language=perl6 myfile.pl


I'm opposed to the command-line pattern of:

$ parrot perl6 myfile.pl

We don't want people to have to type 'parrot' every time they run a script with a language
implemented on Parrot, so there's no value in providing a shortcut that only does half the
job. It could also lead to some nasty conflicts, if someone happens to have a source file with
the same name as one of their installed languages.

Allison