[geos-devel] Inlining + MingW builds

strk at refractions.net strk at refractions.net
Mon Apr 10 08:19:25 EDT 2006


I've given my 'outlined' inlines replication
mechanism a try. Basically there's now a new
implementation file which includes all of
.inl files undefining GEOS_INLINE.

I've tested it and w/out special switches
client code can now link against an INLINED
build of GEOS and run successfully.

This let us drop the -DGEOS_INLINE switch
from geos-config, with which I was pretty
uncomfortable.

A side effect is this should fix MingW,
Cygwin and OSX builds.

Tests welcome.

--strk;

On Mon, Apr 10, 2006 at 11:46:39AM +0200, Mateusz Å?oskot wrote:
> strk at refractions.net wrote:
> > On Mon, Apr 10, 2006 at 11:05:26AM +0200, Mateusz Ã
?oskot wrote:
> >>strk at refractions.net wrote:
> >>
> >>>The rational would be, for a default build, to
> >>>have inlines used by core library, but non-inlined
> >>
> >>Why not to use compiler switches to achive this behaviour?
> > 
> > 
> > Is there such a switch for all compilers ?
> > Or should we make GCC a requirement ?
> 
> Yes, every good and modern compiler provide options to control inlining.
> I'd say it's a must.
> 
> In example, Microsoft VC++ provides:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_.2f.ob.asp
> 
> (I have only GCC and VC++, so I can't check it in other compilers)
> 
> >>>functions to be available for clients.
> >>>I dunno if there's any standard compiler switch for
> >>>this, but we might reproduce it with the custom mechanism.
> >>
> >>I think it's much simplier to use compiler switches instead of custom
> >>mechanism. Here are two that should provide this behaviour:
> >>-fno-inline
> >>-fno-default-inline
> > 
> > 
> > It's surely simpler for developers, but we want a consistent
> > behaviour for builders.
> 
> Makefiles should include those options by default for debug building.
> Next, configure script should provide a possibility to turn it on/off.
> 
> > Note that I'm not happy with shipping the .inl and to require
> > GEOS_INLINE to be defined... so I'm open to discussion.
> 
> I feel it. So, that's why I'm looking for native and life-saving solution.
> 
> >>>For example, we might have an inline.cpp file including
> >>>all of the .inl files with GEOS_INLINE undefined.
> >>>I haven't tested this yet, though.
> >>
> >>If I could comment this approach, I don't like it.
> >>This will scatter code too much, what make maintenance harder.
> >>It'll be hard to navigate, remember which class member is inlined and
> >>which is not, etc.
> > 
> > 
> > CLASS=geom/Coordinate
> > vi -o source/$CLASS.cpp source/headers/geos/$CLASS.{h,inl}
> 
> IMHO, it's not a solution at all.
> 
> Cheers
> -- 
> Mateusz Łoskot
> http://mateusz.loskot.net
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel

-- 

 /"\    ASCII Ribbon Campaign
 \ /    Respect for low technology.
  X     Keep e-mail messages readable by any computer system.
 / \    Keep it ASCII. 




More information about the geos-devel mailing list