Date:	Wed, 28 Apr 1999 10:13:04 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Mark E." <snowball3 AT bigfoot DOT com>, DJ Delorie <dj AT delorie DOT com>
cc:	djgpp-workers AT delorie DOT com
Subject:	Re: v2.03: wrapping up
In-Reply-To:	<199904280446.EAA96618@out5.ibm.net>
Message-ID:	<Pine.SUN.3.91.990428095859.25283J-100000@is>
MIME-Version:	1.0
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

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.

- Raw text -