On Thu, Feb 5, 2009 at 5:28 PM, Jean-Sébastien Guay <jean-sebastien.g...@cm-labs.com> wrote: > I see things from the opposite perspective: if OSG wants to be used > multi-platform, it has to work well on each platform, the way that platform > works. Otherwise, just make VS unsupported and make everyone build through > cygwin if they want to build on Windows... That way gcc is always used and > you don't have to worry about how VS does things.
I strongly disagree with adding lots of platform specific hacks into headers and cpp's. Standard C++ and OpenGL, CMake all exist for a reason - to make code more portable with the need for lots of platform specific hacks and expertise. Once you start adding lots of platform specific code you are on slippery slope on poor maintainability and portability. > If you want a native Windows build, people need to use VS. If OSG has to be > compiled through VS, it needs to conform to how VS does things (and any > other compiler, I'm not putting VS in a special bunch here just putting it > on the same footing as gcc). Just because we use VS doesn't mean that we have to do everything the MS way. The MS way is to code everything for Windows and Windows only, cares for portability are very much against MS's strategic goals of vendor lock-in. Play their game and you end up tied to just a single platform and benefiting that vendor rather than your customers. > The problem is that *in OSG* and *in your opinion*, these warnings add > nothing. But if they exist at all, it must be because they add something > sometimes. The add something sometimes, so you have to review them all carefully and them make a judgement call, once you've made that judgement call and it's clear the code is correct, and the warning misleading then you have to then look at quashing it, but only then. Don't forget that even the include/osg/Export pragam's can be switched off via CMake so you can easily do a periodic double check to see if any of the warnings point to some genuine problem. > Hence my assertion that OSG should not make decisions as to what > warnings to suppress for user code. We'll we did try very hard to avoid the need for pragma's but even MS's own code produces warnings.... > OK, back to trying to find solutions as opposed to opinionated discussions > that don't lead anywhere (I'm talking about me, not you :-) ) > > What we could do is kind of like what (I think) SDL does. Instead of having > each header start with > > #include <osg/Export> > > // rest of header > > it could be something like this: > > #include <osg/HeaderStart> > > // rest of header > > #include <osg/HeaderEnd> Goodness, this is pretty long departure from having clean Standard C++ headers... Adding two header includes to our headers just to quieten down warnings on one specific compiler set, or one specific platform so everyone pays for the convenience of one platform. What happens if you forgot to add the closing HeaderEnd?? What happens if you miss the beginning one? Yep the push/pop won't balance. If I make such a mistake ut wont' effect me working under unix, I won't even spot it, but port my problem code to windows and bang lots of odd problems. This certainly won't make help code portability and maintainability. I won't be seeing this suggestion merged into the core OSG. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
