This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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....
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]