[geos-devel] Re: GEOS build scripts

[Paul Ramsey]

Ah. Let's see if anyone on the list knows. It might just be that C++ takes a 
long time to compile (in general, this appears to be true, at least in GNU 
land).

Quoting strk <strk at keybit.net>:

> The build system works, this is sure.
> What I'm not sure about is the correctness of filed dependencies.
> I do not know wheter automake does take care of deps or if it is
> programmer responsibility to set them somehow.
> My problem is that the build time is very very long, and I'm
> trying to understand if this is due to 'conservative'
> dependencies, autotool paranoia, or C++ compile itself.
> 
> --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
>