This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
RE: excessive stab information
- From: "Andy Chittenden" <AChittenden at bluearc dot com>
- To: "Dave Korn" <dave dot korn at artimi 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:47:34 +0100
- Subject: RE: excessive stab information
that's exactly what we do!
--
Andy, BlueArc Engineering
> -----Original Message-----
> From: Dave Korn [mailto:dave.korn@artimi.com]
> Sent: 28 April 2005 17:32
> To: Andy Chittenden; 'Daniel Jacobowitz'; 'Ian Lance Taylor'
> Cc: binutils@sourceware.org; Martin Dorey
> 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....
>
>