One could implement gcj-x.y as a bash script that parses its
arguments, and optionally does
main_classes=$(jv-scan-x.y --print-main "[EMAIL PROTECTED]")
if [ 1 = $(echo "$main_classes" | wc -w) ]; then
gcj-x.y.real --main=$main_classes ...
else
echo "Multiple classes contain a \`main' method: $main_classes" >&2
echo "Please specify the appropriate class with \`--main=CLASS'." >&2
exit 1
fi
"optionally": if neither `--main=...' nor -c etc. were given on the
command line.
Hmm, apparently jv-scan-3.4 doesn't allow either .class inputs or
[EMAIL PROTECTED]' specifications (*see (gcj)Input and output files), nor
libraries.
.o files can be handled with
nm --format=sysv --extern-only --demangle --defined-only --no-sort
objfiles... \
| sed -n 's/::main(JArray<java::lang::String\*>\*)|.*//p'
.class files could be handled with something like
jcf-dump-x.y --javap
| egrep '^This class:|^ *public static void
"main"\(java\.lang\.String\[\]\)$'
| egrep -B1 'public static void "main"'
| sed -n 's/^This class: \([^,]*\),.*/\1/p'
jcf-dump-3.4 doesn't seem to handle .zip/.jar files.
I don't know how much if any of this is worth implementing.
A cheap alternative would be for gcj to detect the lack of situation
and produce a more helpful error message (mention the `--main' flag).
pjrm.
