This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: MPE Port


  In message <4.1.19990920073855.00c276f0@garfield.dis.com>you write:
  > At 05:35 AM 9/20/99 -0600, Jeffrey A Law wrote:
  > 
  > >Running your new autoconf is going to muck around with the configure files
  > ,
  > >presumably to force them to try and run programs instead of just linking
  > >them, right?
  > 
  > Yes. But, these configure files are determining the characteristics of the 
  > host machine, not the target, are they not? $ac_link is the key, here.
Some are also used to determine characteristics of the target machine; 
libiberty for example.

  > In order to do this another way, what would you like to see? I can build 
  > a script that moves all of the various files into place and provides
  > canned versions of config.h et. al. But, this becomes more of a maintenance
  > nightmare than what I'm doing now. As the OS gets "fixed", there will be
  > multiple versions of these files lying around. I really like the elegance
  > of configure and hate to lose it.
I want to see something that does not muck with the source tree when the user
configures the tools.  The vast majority of the time that's the wrong thing
to do.

If you are replacing ac_link, then maybe the best solution is to get autoconf
enhanced would be the best.  For example, autoconf could have ac_link build
and run the program iff host == target == build.  Or I suspect they might want
to avoid using ac_link for that purpose since it implies that something
linked.  Instead they might want to use ac_run.  Anyway the point is that
this might be best handled by getting autoconf fixed to actually perform the
kinds of tests you need when they are appropriate.




jeff



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]