egcs-1.0.2 installation

[Craig Burley]

>This seems to indicate that you have your object direct _within_ the egcs
>sourcetree. Please try the same with an object tree that does not reside
>there.
>
>To the egcs guys: INSTALL/CONFIGURE does not state this clearly, should I
>submit a patch? 

I'd prefer that configure detect and reject this.  A simple-minded
approach might be something along the lines of:

  # The filename used below must not exist in the source directory!
  INOBJ=in-obj

  touch ${object}/${INOBJ}
  if [ find ${srcdir} -name ${INOBJ} ] then
      echo some whine
      exit 1
  fi
  rm -f ${INOBJ}
  ...

However, that might make the configuration process much slower
than it is already (especially on NFS setups?), so a more clever
approach is probably required, e.g. one that actually parses
the text of the relevant pathnames (which might be challenging
when handling non-UNIX systems).

Reason for this is that I feel a general prioritized approach to
dealing with things like this (situations where the software won't
work quite right) looks something like:

  1.  Make it work in that situation.

  2.  Make it detect that situation and reject it as soon as possible
      (ideally, right when the user who creates the situation does so,
      instead of complaining to user B that user A set things up wrong),
      using a nice clear error message.  Document that the situation must
      not occur, as appropriate.

  3.  Document that the situation must not occur.

  4.  Don't cope with it at all, just tell people who complain that
      they screwed up.

I think we all agree that egcs (and gcc?) are at Level 4 right now and
that it's at least fairly easy to move up to Level 3, but if we
can move to Level 2 or 1, I'm all for it.  But I'm not confident
enough in my own skills vis-a-vis portable shell-script programming
to offer a patch myself at this time.

        tq vm, (burley)