This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: MPE Port
- To: Mark Klein <mklein at dis dot com>
- Subject: Re: MPE Port
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 20 Sep 1999 10:13:21 -0600
- cc: gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
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