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)

2008/11/16 Joseph S. Myers <>:
>> 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.)

Fully agreed. What is the problem then? There are many things in GCC
that still need to be done. Your argument is that this is a little
step. Well, as long as it is not a step backwards, I am happy. I don't
see many volunteers to take any steps whatsoever, so I don't think
this is hampering anyone's work.

I actually tried to define a cleaned interface but it is not clear at
all what belongs where. Moving the files elsewhere helps to clarify
this, as we are seeing in this thread.

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

Funny, nobody bothered about the interface of line-map until I
proposed moving the files to its own library. I wonder why physical
accidents of how files are arranged (or even which functions appear on
those files) brought these interfaces issue to your mind.

Unfortunately, I seriously doubt that even with clean interfaces
existing front-ends that do not use common code will use the
libraries. That would require apart from clean interfaces, the
addition of many missing features.

I do think that moving together related code could help in the future
to progressively define those interfaces. At the minimum, it will help
to not make it progressively harder.



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