X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date: Wed, 3 May 2000 12:46:21 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender: broeker AT acp3bf
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp-workers AT delorie DOT com
Subject: Re: gcc 3.0
In-Reply-To: <Pine.SUN.3.91.1000503123405.4851b-100000@is>
Message-ID: <Pine.LNX.4.10.10005031243550.1423-100000@acp3bf>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Wed, 3 May 2000, Eli Zaretskii wrote:

> 
> On Wed, 3 May 2000, Hans-Bernhard Broeker wrote:
> 
> > Another drawback that I recognized as an afterthought, yesterday night:
> > gcov-support will not work in non-LFN situations. The filenames it uses
> > (source.c.bb, source.c.bbg, source.c.da and source.c.gcov)  require LFN
> > support. The filename generation mechanism may have to be re-thought, for
> > 8.3 filesystems.
> 
> Removing the .c extension before appending the .bb etc. ones will 
> probably be good enough.

For typical C sources: yes. But if there is executable inline code in a
header file, this scheme would break.

	source.c --> source.bb
	source.h --> source.bb

This would happen especially often for C++ code with all those class
inline methods. OTOH, there's not much else one could do (short of
creating subdirectories and writing filenames like 'bb/source.c',
'bbg/source.c' and the like).

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.