Re: egcs testsuite & dejagnu : A special case?

[Craig Burley <burley@gnu.org>]

>The way dejagnu `solves' this is as follows:
>It picks a foobar.cc file and collects all the gcc parameters it
>needs to compile it (the -B, -L etc).  From that it determines
>where the libstdc++ resides that apparently is wanted (from a
>-L.*stdc++/).  It remembers this path in a variable, compiles the
>program and then sets explicitly the LD_LIBRARY_PATH environment
>variable to this path before executing the test program.
>If you hide the -L paths from dejagnu, it won't be able anymore
>to determine where the wanted libstdc++ is and thus it won't be
>able to set the LD_LIBRARY_PATH environment variable.

Would not another driver option like --print-program-name=whatever
be more appropriate than this approach?  E.g. --print-library-path
or something?

This is yet another point in favor of a weird, old idea I've been
seeing other points in favor of lately.  Namely:

  gcc ("compilers" in general that preprocess/compile/link) should
  also be able to *run* programs!

That'd be pretty cool, and would make for an obvious place to
solve the dynamic-library-path problem.  And it hearkens back
to systems like TOPS-10, which I used to use.  Not sure what
other problems it'd bring, though.

In any case, it sure seems like there's a lot of investment in
the idea that dejagnu, and perhaps other packages, should have
intimate knowledge of gcc command-line options and internal
operations of the driver.  After seeing all the problems this
has caused over and over again for years, I'd have thought it was
a slam-dunk to convince everyone that taking the time and
trouble to define, publish, and implement a clean interface to
the revelant aspects of how gcc does its job would be worthwhile,
and would have saved a lot of trouble had it been done years ago.

But I guess I'm losing my enthusiasm for doing something that
would cause people concern.  Like significant tabs in makefiles,
perhaps we'll just learn to live with the problems that inevitably
result from design mistakes we're unwilling to correct because
of the "huge existing installed base".  :)

In case I haven't made myself clear: it is an outright design
*flaw* that gcc requires any *options* to invoke it properly,
regardless of where it lives.  That is, if you define "built
but not installed" is not invokable, then there's no bug,
except that any other package (or `make check') that tries
to invoke it there is, by definition, broken because it tries
to do so.

But if you say that -B, -L, etc. are required to invoke gcc
so it works as it was intended to (as built), then you're
talking about an outright design flaw.  A command is supposed
to be sufficient to specify the entire data base of whatever
the command needs to properly operate.  Environment variables
and options needed to effect that are simply work-arounds for
a buggy design.  And IMO that extends to dynamic libraries as
well.  So much time wasted because people are willing to live
with obviously bad designs, always resulting in lots of confusion,
subtle programming errors, and the like.  It's understandable
why Microsoft repeats the mistakes of 20 years ago when it
catches up on decades-old technology; I'm not so sure the rest
of us have any excuse for that.

        tq vm, (burley)