gdb testing: get_compiler_info does not work with hp-ux aCC

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

>From the "all the world is not gcc" department.

I'm running the test suite on native hppa2.0w-hp-hpux11.11 with hp-ux
ansi c and hp-ux aCC, and I'm getting results.  Rather awful results but
the test suite is running.

When I use /opt/ansic/bin/cc, the symbol $hp_cc_compiler gets set
properly.  But when I use /opt/aCC/bin/aCC, the symbol $hp_aCC_compiler
is never set.

I dug into get_compiler_info and it's a mess.  It calls different
procedures on different targets.  It calls "what" on the compiler
executable, which is tough when my compiler executable is a shell script
named "gcc" that chains to the real aCC.  (I wrote a fake "what" and
stuck it in my path).  And it has its own private copy of the mechanism
for looking up compiler executable names instead of just calling
"gdb_compile" with the "preprocess" option.

That last part is the part that doesn't work on hpux.  It uses the C
compiler for both "compiler.c" and "compiler.cc", no matter what I try.
So hp_aCC_compiler is never set.

I have some ideas for fixing this problem.  My best idea is to run
"[gdb_compile $ifile "" preprocess]", capture the result on standard
output, and "eval" it.  This replaces "capture the result in a file and
source it".  The command "gcc -E compiler.c -o file.o" does not comply
with Single Unix Spec v3 and does not work on hp-ux; and the command
"gcc -E compiler.c > file.o" involves an argument with dejagnu that I
don't even want to start.

Anyways.  One side effect is that the foo.ci files might go away because
get_compiler_info can do the job internally.  This should not matter to
the test scripts.  But there are about six scripts that explicitly call
"source ${binfile}.ci".  They shouldn't do this anyways, because
get_compiler_info already does it.

So my plan is:

  write and test a patch to kill the bogus "source ${binfile}.ci"
  submit that patch for approval
  write and test a patch to rewrite get_compiler_info
  submit that patch for approval

Of course, I could always have "get_compiler_info" create an empty
file for compatibility.  But since the references to ${binfile}.ci
can all die right now, I'd rather just do that first.

Does this sound okay?

Michael C