This is the mail archive of the mailing list for the GCC 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: [4.5] [RFC] Move line-map.* to its own library (libloc)

On Sun, 16 Nov 2008, Manuel López-Ibáñez wrote:

> 2008/11/15 Tom Tromey <>:
> >>>>>> "Manuel" == Manuel López-Ibáñez <> writes:
> >
> > Manuel> The following patch moves line-map.* and other stuff related to
> > Manuel> locations to a library called libloc. Anything that only needs
> > Manuel> location info does not need to link against libcpp or include libcpp.h
> > Manuel> anymore.
> >
> > Is the rationale for this just to avoid pulling in the rest of libcpp?
> > That doesn't seem like a big enough benefit to justify making a new
> > library.
> No, that is a secondary effect of the main motivation. The main
> motivation is to start making GCC more modular. The current situation

> Line-maps is just the (current) internal working of libloc, we may
> decide change it in the future. A better interface would define the
> location-related functions that we need and not simply the functions
> that line-map provides.

I would suggest that the important part of modularity is not the physical 
arrangement of files into libraries, but the definition of clean 
interfaces and ensuring code uses those interfaces instead of underlying 
internals.  Forming such libraries may help emphasise the division between 
interface and implementation, but is not the important part.  (The parts 
can still be done in either order, but if the first step is moving the 
files then the important part still needs to be done afterwards.)

Or is your argument that potential developers are not contributing because 
of the physical accidents of how files are arranged, rather than because 
of the interfaces being poorly defined (which many undoubtedly are)?  And 
that with such libraries visibly present more developers would appear to 
clean up the interfaces to the libraries and make more code using its own 
ad hoc diagnostic (etc.) systems use the libraries instead?

Joseph S. Myers

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