[geos-devel] Re: GEOS build scripts
Ferdinando Villa
ferdinando.villa at uvm.edu
Wed Apr 14 12:03:37 EDT 2004
The problem seems to come from wanting it all in a single library; since
the files are too many to fit on ld's command line, libtool builds the
library piecewise, which takes a very long time; plus, the library needs
to be rebuild even when a single object file changes. When we discussed
the code organization, I was in favor of building separate libraries and
use a helper script (geos-config --libs) to do the link, but was
outvoted in favor of the single library organization... I guess this was
the unforeseen drawback. Other than restructuring everything, I don't
see many options here (on the other hand, I'm recovering from anesthesia
right now, so I may see options when I wake up!)
sorry
ferdinando
On Wed, 2004-04-14 at 11:30, strk wrote:
> The disk space requirement empirically found:
>
> When all the intermediate .o are around:
> /dev/hda3 7874560 6199124 1275420 83% /usr
>
> After intermediate .o removal:
> /dev/hda3 7874560 2991172 4483372 41% /usr
>
> It's a +3GB of disk space (and write) requirement !!
>
> --strk;
>
> On Wed, Apr 14, 2004 at 05:19:23PM +0200, strk wrote:
> > Just to let you understand my problem:
> > touching source/index/strtree/AbstractSTRtree.cpp
> > after a complete build makes the next build take
> > 4,30 minutes on a 1668.736 Mhz CPU with 775MB ram.
> >
> > The link part is the longer. The linker is run for *every* object
> > file creating ALL intermediate objects:
> >
> > /usr/bin/ld -r -o .libs/libgeos.la-24.o .libs/TopologyException.o .libs/libgeos.la-23.o
> > /usr/bin/ld -r -o .libs/libgeos.la-25.o .libs/Triangle.o .libs/libgeos.la-24.o
> > [..]
> > /usr/bin/ld -r -o .libs/libgeos.la-180.o .libs/UnsupportedOperationException.o .libs/libgeos.la-179.o
> >
> > Then the last object is made a shared library, and the libgeos.la-#.o files
> > are removed.
> >
> > gcc -shared .libs/libgeos.la-180.o -Wl,-soname -Wl,libgeos.so.1 -o .libs/libgeos.so.1.0.0
> >
> > Finally all object files are appended (again with an 'ar' run each) to
> > the libgeos.a archive:
> >
> > ar cru .libs/libgeos.a RelateNode.o
> > : .libs/libgeos.a
> > ar cru .libs/libgeos.a RelateNodeFactory.o
> > : .libs/libgeos.a
> >
> > Note that the incremental object linkage requires a lot of disk
> > space also, about the factorial of average object size.
> >
> > The tools I'm using are:
> > ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)
> > automake (GNU automake) 1.7.7
> >
> >
> > --strk;
> >
> > On Wed, Apr 14, 2004 at 07:47:33AM -0700, Paul Ramsey wrote:
> > > Not sure I understand the question. If you touch code, make is required
> > > to recompile it, and everything else that depends on it. So if you
> > > touch everything, everything will recompile, even if there are no
> > > actual changes, except to the file change date. I think the build
> > > system is working OK. Having everything centralized in geom is a bit
> > > fussy, but given the volume of changes (low) I think it works fine.
> > >
> > > Paul
> > >
> > > On Tuesday, April 13, 2004, at 11:39 PM, strk wrote:
> > >
> > > > Hi,
> > > > I've seen that touching every single piece of code makes
> > > > the build required to start from scratch. Is there anything
> > > > I can do to make the build process quicker ?
> > > > Should automake take care of real dependencies or that is
> > > > a task of myself ?
> > > >
> > > > TIA
> > > > --strk;
> > > >
> > > > On Tue, Apr 13, 2004 at 10:03:49AM -0400, Ferdinando Villa wrote:
> > > >> Using the void* and relying on a virtual for proper deletion is a
> > > >> pretty
> > > >> unsafe way of doing it (not to mention ugly). A better alternative
> > > >> could
> > > >> be something like this - a bit messier, but once done, it takes care
> > > >> of
> > > >> it all:
> > > >>
> > > >> 1. define these within the class that has the void*
> > > >>
> > > >> class _handler
> > > >> {
> > > >> public:
> > > >> void* obj;
> > > >> virtual ~_handler() {}
> > > >> };
> > > >>
> > > >> template <typename T>
> > > >> class handle : public _handler
> > > >> {
> > > >> public:
> > > >> handle(T* o) { obj = o; }
> > > >> handle(const handle& lh)
> > > >> { obj = lh.obj; }
> > > >> virtual ~handle() { T* t = (T*)obj; delete t; }
> > > >> };
> > > >>
> > > >> 2. have a pointer to _handler initialized to zero instead of void*,
> > > >> and
> > > >> delete it in the destructor if it's non-zero;
> > > >>
> > > >> _handler _h
> > > >>
> > > >> yourclass(): _h(0) ...
> > > >> ~yourclass() { if (_h) delete _h; }
> > > >>
> > > >> 3. add a set/get method like
> > > >>
> > > >> template <typename T>
> > > >> void set_thingy(T* lh)
> > > >> {
> > > >> _h = new handle<T>(lh);
> > > >> }
> > > >>
> > > >> template <typename T>
> > > >> T* get_thingy()
> > > >> {
> > > >> return reinterpret_cast<T*>(_h->obj);
> > > >> }
> > > >>
> > > >> Even better if the _h pointer is a smart pointer, which allows the
> > > >> containing object to be copied and passed around safely, but that's
> > > >> more
> > > >> setup. You can call the set_methods as a regular method:
> > > >> set_thingy(new
> > > >> thing) and that will create the proper class that will manage the
> > > >> deletion properly. The get method requires the template parameter. Of
> > > >> course this substitutes one allocation with two, so it's not really
> > > >> appropriate if it has to be called continuously, but then the void*
> > > >> thing isn't, either.
> > > >>
> > > >> Ciao,
> > > >> ferdinando
> > > >>
> > > >> On Tue, 2004-04-13 at 07:20, Paul Selormey wrote:
> > > >>> According to the JTS docs, this is to be used for coordinate
> > > >>> reference
> > > >>> system,
> > > >>> and it most systems this could be implemented as geometry filter but
> > > >>> the
> > > >>> geomety
> > > >>> may not be applicable to some existing systems.
> > > >>>
> > > >>> I think an abstract class (interface) will do with at least a
> > > >>> "delete"
> > > >>> method to let
> > > >>> the object handle its own deletion. On both Java and .NET which
> > > >>> supports GC,
> > > >>> there was no need to consider this.
> > > >>>
> > > >>> BTW, I have realized work on the JTS 1.4 updates is progressing,
> > > >>> when is the
> > > >>> release date?
> > > >>>
> > > >>> Best regards,
> > > >>> Paul.
> > > >>>
> > > >>> ----- Original Message -----
> > > >>> From: "strk" <strk at keybit.net>
> > > >>> To: "Yury A. Bychkov" <me at yury.ca>
> > > >>> Cc: <geos-devel at geos.refractions.net>
> > > >>> Sent: Tuesday, April 13, 2004 5:23 PM
> > > >>> Subject: [geos-devel] userData for Geometry
> > > >>>
> > > >>>
> > > >>>> The Geometry class has a void *userData that is
> > > >>>> deleted at Geometry detetion time.
> > > >>>> Wouldn't it be appropriate to define a class from
> > > >>>> which userData should derive ?
> > > >>>> The compiler warns that void * cannot be safely deleted.
> > > >>>>
> > > >>>> --strk;
> > > >>>> _______________________________________________
> > > >>>> geos-devel mailing list
> > > >>>> geos-devel at geos.refractions.net
> > > >>>> http://geos.refractions.net/mailman/listinfo/geos-devel
> > > >>>>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> geos-devel mailing list
> > > >>> geos-devel at geos.refractions.net
> > > >>> http://geos.refractions.net/mailman/listinfo/geos-devel
> > > >> --
> > > >>
> > > >> _______________________________________________
> > > >> geos-devel mailing list
> > > >> geos-devel at geos.refractions.net
> > > >> http://geos.refractions.net/mailman/listinfo/geos-devel
> > > >>
> > > Paul Ramsey
> > > Refractions Research
> > > Email: pramsey at refractions.net
> > > Phone: (250) 885-0632
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
--
More information about the geos-devel
mailing list