After discussing the idea with Allison, we both believe that Parrot should be
able to produce a single PBC file from a command like:
parrot -o all_files.pbc file1.pir file2.pir ... filen.pir
-- c
It'd probably make sense to define some clear rules on how symbol
conflicts are handled up front. As it's always nice to know which :main
to invoke. :) A possible rule could be "the version of the symbol that
appears in 'left most" file has precedence". Alternatively, a symbol
collision could just be a fatal error.
-J
--
>
> After discussing the idea with Allison, we both believe that Parrot should
> be able to produce a single PBC file from a command like:
>
> parrot -o all_files.pbc file1.pir file2.pir ... filen.pir
Well, that exists already and is named pbc_merge. pbc_merge takes .pbc input
only, but this shouldn't be a problem.
leo
pbc_merge doesn't allow multiple :load routines. What we're looking for
is more of a Parrot version of .par/.jar/.pkg: bundle up all the files
you need for a particular application into a single file. Not a PBC, but
some form of "archive" or "package" format.
Allison
That's a bug, Shirley.
> What we're looking for is more of a Parrot version of .par/.jar/.pkg:
> bundle up all the files you need for a particular application into a
> single file. Not a PBC, but some form of "archive" or "package" format.
I don't see any harm in .zip and .tar and [archive method of choice]
plugins.
--
Chip Salzenberg <ch...@pobox.com>
Currently it's a feature. Only one :load routine is allowed per PIR
file, and pbc_merge basically just packs all the compiled code together.
I could argue that maybe we should allow multiple :load routines, but
what about :main routines?
>> What we're looking for is more of a Parrot version of .par/.jar/.pkg:
>> bundle up all the files you need for a particular application into a
>> single file. Not a PBC, but some form of "archive" or "package" format.
>
> I don't see any harm in .zip and .tar and [archive method of choice]
> plugins.
Seems like a good way to approach it.
Allison
=head2 Subpragma
This is a list of zero or more items with the following meanings:
=over 4
=item :main
Define "main" entry point to start execution. If multiple subroutines
are marked as B<:main>, the B<last> marked subroutine is entered.
=item :load
Run this subroutine during the B<load_library> opcode.
B<:load> is ignored, if another subroutine in that file is marked with
B<:main>. If multiple subs have the B<:load> pragma, the subs are
run in source code order.
=cut
please also see the tests, at F<t/pmc/sub.t:558-605> (inline below)
which seem to match the docs.
open S, ">$temp" or die "Can't write $temp";
print S <<'EOF';
.pcc_sub :load _sub1:
print "in sub1\n"
returncc
.pcc_sub :load _sub2:
print "in sub2\n"
returncc
EOF
close S;
pasm_output_is(<<'CODE', <<'OUTPUT', "load_bytecode autorun both");
.pcc_sub _main:
print "main\n"
load_bytecode "temp.pasm"
print "loaded\n"
find_global P0, "_sub1"
invokecc P0
print "back\n"
end
CODE
main
in sub1
in sub2
loaded
in sub1
back
OUTPUT
system(".$PConfig{slash}parrot$PConfig{exe} -o temp.pbc $temp");
pasm_output_is(<<'CODE', <<'OUTPUT', "load_bytecode autorun both in pbc");
.pcc_sub _main:
print "main\n"
load_bytecode "temp.pbc"
print "loaded\n"
find_global P0, "_sub1"
invokecc P0
print "back\n"
end
CODE
main
in sub1
in sub2
loaded
in sub1
back
OUTPUT
hope that helps clarify the current behavior a bit.
~jerry