Path: utzoo!utgpu!watmath!uunet!garfield!michael
From: michael@garfield.MUN.EDU (Mike Rendell)
Newsgroups: gnu.gcc
Subject: Re: adding environment variables to gcc.c for pass/file locations
Message-ID: <5200@garfield.MUN.EDU>
Date: 24 May 89 20:09:11 GMT
References: <4463@omepd.UUCP>
Reply-To: michael@cauchy.UUCP (Michael Rendell)
Organization: Memorial University of Newfoundland
Lines: 52

In article <4463@omepd.UUCP> mcg@mipon2.intel.com (Steven McGeady) writes:
>The following diffs demonstrate my addition to 'gcc' of support for
>environment variables which control where gcc finds its various directories,
>programs and support files.
>
>I have tried to make these as general-purpose as possible, and have not
>included features that I wouldn't think generally needed.  However, it
>is clear to me that these features are of primary interest to people
>who are building or working in a cross-compilation environment, where
>the host is not the same as the target processor, although they also
>may be of some use to those who switch between the GNU assembler and
>linker and the standard system programs.

I was thinking about doing the same thing for the same reasons.  The solution
I came up with is to move the "spec" strings into a configuration file.  The
config file used could be specified as a (single) environment variable (e.g.
GCC_CONFIG=/usr/local/lib/gcc-config/{atari,sun2,etc}) or as a flag to gcc.
Each line of the config file is either a spec or a path - the first word of
the line indicates what spec/path is being specified (for compiler specs, the
second word is the suffix).  A config file would look something like:

	# config file for <whatever>
	compiler .c cpp %{nostdinc} %{C} ...
	compiler .cc cpp -+ ...
	compiler .i cc1 ...
	compiler .s %{!S:as ...}
	compiler .S cpp ...
	link %{!c: ...}
	asm-spec ...
	cpp-spec ...
	cc1-spec ...
	link-spec ...
	lib-spec ...
	startfile-spec ...
	signed-char-spec ...
	exec-prefix ...
	startfile-prefix ...

multiple compiler, exec-prefix, and startfile-prefix values may be specified.

The default values for the host machine could be compiled into gcc, or read
from a `standard' location e.g. "/usr/local/lib/gcc-def-config" (there is a
chicken-and-egg problem here).  Anyone see any problems with doing this?  The
advantages over mcg's solution are that is more general (you get to specify
everything) and uses fewer environment variables, the disadvantage is that it
does not allow explicit specification of the path for a particular program
(could be extended to have cpp-path, asm-path, etc).
I will be trying this out on the weekend - if it works out well I will post
the diffs.

--
Mike Rendell - Dept. of Comp. Sci, Memorial University of Newfoundland