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: > [EMAIL PROTECTED] wrote: > > On Mon, Apr 10, 2006 at 11:05:26AM +0200, Mateusz à ?oskot wrote: > >>[EMAIL PROTECTED] 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@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. _______________________________________________ geos-devel mailing list geos-devel@geos.refractions.net http://geos.refractions.net/mailman/listinfo/geos-devel
