This is the mail archive of the
mailing list for the GCC project.
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 <email@example.com>:
> >>>>>> "Manuel" == Manuel López-Ibáñez <firstname.lastname@example.org> 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