prefix, etc. with dollar or tilde?

[Jay K]

[plain text this time]

> Real VMS support probably requires redefining

Right, now I realize a bit more.
Tristan gave me a big clue: "define VMS logical GNU".
I didn't mean the current directory necessarily, but the directory of the executable.
  In my example I admit I conflated them.

I can probably get close with -prefix=bindir=libdir=libexecir=includedir etc.
though I don't think that fully flattens things (would still have lib/gcc/4.5.0).

Nevermind though, I just have to fixup things in the existing supported way.

"~" could stand for having gcc getenv("HOME") at runtime.
But nevermind.

The VMS mechanism is actually very flexible I just didn't/don't understand it well.

Thanks,
 - Jay


> To: jay.krell@cornell.edu
> CC: gcc-help@gcc.gnu.org
> Subject: Re: prefix, etc. with dollar or tilde?
> From: iant@google.com
> Date: Tue, 25 May 2010 07:33:31 -0700
> 
> Jay K <jay.krell@cornell.edu> writes:
> 
>> it might be nice if I could say e.g. -prefix=~/gnu.
>>   Currently prefix must be a full path.
> 
> Unix does not have any path like ~/gnu.  The ~ is, by convention,
> expanded by the shell to something like /home/gnu.  So this idea does
> not make sense on Unix.  Real VMS support probably requires redefining
> the notion of a path in some way.  E.g., DOS pathnames are also
> different, and the toolchain has support for that centered on
> include/filenames.h.  I'm sure VMS will require different kinds of
> support, but that seems to me like the place to start.
> 
> 
>> Might also be nice for gcc to look in its own directory for cc1, or heck, even .h and .a/.lib files?
> 
> That would be an extremely bad idea.  gcc should not change behaviour
> based on the directory where you run it.  (Unless you explcitly add
> the current directory to various environment variables, which is in
> itself a bad idea.)
> 
> Ian