X-Authentication-Warning: acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs Date: Sun, 25 Mar 2001 16:14:09 +0200 (MET DST) From: Hans-Bernhard Broeker X-Sender: broeker AT acp3bf To: Eli Zaretskii cc: djgpp-workers AT delorie DOT com Subject: Re: About release of gcc-2.95.3 for DJGPP In-Reply-To: Message-ID: 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 Sun, 25 Mar 2001, Eli Zaretskii wrote: > On Sun, 25 Mar 2001, Hans-Bernhard Broeker wrote: > > > OTOH, it's not strictly necessary for gcov itself to work in SFN, as long > > as an LFN environment is available at all: the data files carry short > > names (foo.bb, foo.da, foo.bbg), and it should suffice to run gcov in the > > LFN environment, later, in case the target program itself doesn't work in > > LFN. > > This is extremely inconvenient, since coverage analysis usually involves > repeated runs of the program with different inputs, using the coverage as > guidelines. Fully agreed. I wrote the above reply before seeing all of the answers in that thread which proceeded to define a scheme that might, indeed, actually work on DOS, while not creating too much of a deviation from the documented behaviour as found in the gcov docs. SFN is a pest, but that method of filling in the remainder of the filename with 'gcov', from the right, should indeed work in most of the typical cases. > Having to reboot the machine or copy the data files to > another machine slows down this process tremendously. Sure. Except maybe in NT, where the output generated by a DJGPP program restricted to SFN should be analysable by gprof from a native GCC port (after patching it for binary file handling, that is :-), and all that without any reboot. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.