Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: X-no-Archive: yes Return-Read-To: markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at Return-Received-To: markus DOT oberhumer AT jk DOT uni-linz DOT ac DOT at Date: Fri, 30 Apr 1999 00:55:52 +0200 (CEST) From: "Markus F.X.J. Oberhumer" To: djgpp-workers AT delorie DOT com Subject: Re: v2.03: wrapping up Cc: Andris Pavenis , DJ Delorie , "Mark E." Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id SAA19078 Reply-To: djgpp-workers AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk I think it would be better to avoid any metacharacters ('%' is still used in dos shells) and use /dev/env/xxx instead. Of course, the correct name would be /proc/self/env/xxxx, but /proc can wait for djgpp 3.0 ;-) Markus On 29-Apr-99 Eli Zaretskii wrote: > > On Wed, 28 Apr 1999, I wrote: > >> > A special filename that evaluated to $DJDIR would also work (e.g. >> > /dev/djgpp like Andris suggested a few days ago) or if there were >> > someway of evaluating a env. variable in a filename (e.g. >> > /dev/env/djdir/). >> >> Perhaps a better way would be to invent a ficticious drive called, say, >> `{', and then use /dev/{/DJDIR etc.? > > After some thought, I like Mark's idea about automatic expansion of > environment variables a lot. I implemented it in putpath.c, and the > code doesn't seem too large. See the diffs below. Please comment on > the idea and its implementation, so we could put this problem behind > us. > > What the new code does is to let you say things like > /dev/%/DJDIR/include or /dev/%/DJDIR?c:/djgpp?/include or even > /dev/%/C_INCLUDE_PATH?/dev/%/DJDIR?/include (the part between the `?'s > is the default value that gets used if the environment variable is > undefined or empty). > > I've chosen the `%' as the pseudo-device name because it seems to be > not too special in Bash. But if it proves to be a bad idea, we could > find some other character, I guess. > > This should allow to put a -imacros option into the cpp section of the > specs file that goes with the compiler, and have it seamlessly pull in > the sys/version.h header that defines the version symbols. > > Also, this will allow to define file names in --prefix and other cases > when building ported GNU tools and have them transparently expand at > run time to the right directories/file names. > > Please comment on this idea and its implementation, and whether > solving the problems with __DJGPP__ and __DJGPP_MINOR__ (by > recompiling the GCC/EGCS distribution with the library that supports > this feature) is an okay solution. > > I didn't check in the changes below yet, but if we agree on this being > the solution for the version symbols, I would recommend to get this > into v2.03. > > Last, but not least: thanks to Mark for suggesting this simple but > powerful feature! Even if we don't use it for the immediate problem, > I think it should be part of DJGPP v2.04. ----- Markus F.X.J. Oberhumer ----- ----- http://wildsau.idv.uni-linz.ac.at/mfx/ ----- ----- 5E CB 5C 85 DE AF 9E BF E9 DA 7E 6A 39 F8 CC 67 ----- 3 WARPS TO URANUS