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:32:25 +0100
- Subject: RE: excessive stab information
----Original Message----
>From: Andy Chittenden
>Sent: 28 April 2005 17:26
>> .... 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.
>
> but then if you have 1000s of published directories, then the include
> path becomes unwieldy and you need to change it for each new subsystem
> that gets published. It also means that there's a risk of clashes if
> someone's called their header file something generic - making sure that
> each header file in each subsystem is uniquely named across the whole
> system is unrealistic. By using a directory structure for the published
> headers, we keep the compiler's include path manageable, it makes the
> compiler find header files faster (ie it's not searching 1000s of
> directories) and we avoid name clashes between sub-systems.
Well, what would make that manageable would be if all the published
directories lived under one path, and the individual #includes then
specified #include "relative-subdir/published_foo.h". This is how most
libraries work: lib FOO publishes its header files in a subdir called FOO
under /include, and users of those libraries specify #include
"FOO/foo_interface.h". No namespace pollution, because the subdir named
after the module keeps all the different modules' interfaces separate. No
1000's of published directories in the include path, just the top-level
/include, with the include paths specified relative to that. And no
difference between how the client of a library refers to its published
interface header and how the internal components of that library do so.
Have I accounted for all your objections there?
cheers,
DaveK
--
Can't think of a witty .sigline today....