Date: Wed, 28 Apr 1999 10:13:04 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: "Mark E." , DJ Delorie cc: djgpp-workers AT delorie DOT com Subject: Re: v2.03: wrapping up In-Reply-To: <199904280446.EAA96618@out5.ibm.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Thanks for working on this. On Wed, 28 Apr 1999, Mark E. wrote: > It's still true in the latest sources. One solution that looks promising is > to define a custom spec. Cygwin has a custom spec in their > configuration to hold the mingw32 include path. I'm not sure I understand. We do have our custom spec: it's the specs file, and it is precisely the reason for all this thread. In the past, the compiler and the library were always released together, like most commercial products do, so there was no problem to have lib/specs that fits both the compiler and the library. But now they are released separately. Since the specs are more tightly coupled with the compiler, we would like the specs file to be part of the compiler distribution. This creates a problem of updating the specs when the library changes; we have succeeded to limit the problem of these changes to defining __DJGPP__ and __DJGPP_MINOR__ to the right version of the library. Now: how would a custom spec solve this? > I see no reason why > we couldn't apply the same method to create a custom DJGPP spec to > hold the value of $DJDIR or whatever value is preferred. $DJDIR is determined at run time, so it cannot be compiled into a static spec. If the specs syntax would allow to expand an environment variable, we could use that, but it seems it doesn't. One of my suggestions was to add such a feature to the specs syntax, and then use it. > The problem > is the cut off date of feature submissions for egcs 1.2 was a few days > ago. Of course there's no reason we couldn't add it in for our 1.2 and > submit it so it gets in to 1.3. Right. I don't see any reason to bother about EGCS release dates for now. Let's concentrate on finding a solution, and take care of submitting that to the maintainers later. > 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.? If this is a preferred solution, let's do it. Does anybody else have comments on such automatic expansion inside putpath? DJ? > Problem is such a feature, if added, would have to wait for 2.04. It's up to us. If we decide this feature is important enough, we can put it into 2.03.