Bug#215445: Possible wrapper implementation

[Peter Moulder <pmoulder@bowman.csse.monash.edu.au>]

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 "${inputs[@]}")
  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
`@FILE' 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.