[geos-devel] Re: GEOS build scripts
strk
strk at keybit.net
Wed Apr 14 11:30:13 EDT 2004
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
More information about the geos-devel
mailing list