This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: excessive stab information
- From: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'Andy Chittenden'" <AChittenden at bluearc dot com>,"'Daniel Jacobowitz'" <drow at false dot org>,"'Ian Lance Taylor'" <ian at airs dot com>
- Cc: <binutils at sourceware dot org>,"'Martin Dorey'" <mdorey at bluearc dot com>
- Date: Thu, 28 Apr 2005 17:01:57 +0100
- Subject: RE: excessive stab information
----Original Message----
>From: Andy Chittenden
>Sent: 28 April 2005 16:50
>> Why don't you sort out the search path in the makefile so that the
>> publishing library also finds the public interface header
>> first? That would
>> be good practice and achieve the desired consistency.
>>
>
> 'cos it doesn't work. Consider the case where we have a directory that
> publishes bar.h to foo/bar.h. In the source directory, the cpp files
> #include "bar.h". In other directories, users #include "foo/bar.h". If
> the source file was also #including a currently private header file
> "fred.h", that header file can be published later without the need to
> change existing source.
Ah, well, that's a problem. I'd have said that the published-interfaces
directory "foo" should be in the default search path so that published
interfaces are accessible everywhere; the users can #include "bar.h". And
if someone wanted to create a private header file in some source dir called
"bar.h", and was complaining that it would be overridden by the published
"bar.h", well, that's just as much their fault as if they'd tried to create
a private header file called "stdlib.h" and were complaining about the
system's one overriding their own.
cheers,
DaveK
--
Can't think of a witty .sigline today....