[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@xxxxxxxxxxx
> CC: gcc-help@xxxxxxxxxxx
> Subject: Re: prefix, etc. with dollar or tilde?
> From: iant@xxxxxxxxxx
> Date: Tue, 25 May 2010 07:33:31 -0700
>
> Jay K <jay.krell@xxxxxxxxxxx> 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
