This is the mail archive of the gcc-patches@gcc.gnu.org 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)


Hello Manuel,

* Manuel López-Ibáñez wrote on Thu, Nov 20, 2008 at 02:20:17PM CET:
> 2008/11/18 Ralf Wildenhues <Ralf.Wildenhues@gmx.de>:
> > BTW, even with the desire/need to separate the code into its own
> > library, I completely fail to see why it needs to be in a separate
> > directory, with a separate configure script and separate makefile.
> >
> > You don't do such things below gcc/, and they are certainly not
> > required from the build system.  And IIUC you are not going to use
> > libloc as a stand-along library (i.e., independent of GCC) anyway,
> > right?
> 
> To be honest: I don't have any idea how to do this within gcc/. I
> followed libcpp model and it worked. Is there something similar that I
> can use as a model?

libbackend.a, for example.  See gcc/Makefile.in.

Or you could build it alongside libcpp in libcpp/.  Or in gcc/../libloc.
Either way it would be adding about 6 lines to some Makefile.in and a
couple of gcc/Makefile.in to point downstream code at header file path
and library path.

Just to clarify, all my comment was intending to address was a build
system POV, I did not intend a design requirement.  Anyway, from a
build-system POV, it seems pointless that the GCC tree has so many
configure scripts most of which do the same thing, but all need to run
separately and so on.  If the directories contain (once-)independent
packages, that is understandable, but otherwise all it produces is build
overhead; in the end, that's not going to help spur development.
I understand the requirement to remain compatible with the src/ tree but
that doesn't mean you can't have one configure script for the bulk of
the target libraries which are not independent projects.

Whereever you decide where this library should end up, if you have
trouble implementing the rules for it, feel free to ping me off-list.

Cheers,
Ralf


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