Alright then. I guess adopting a kind of Path structure is not on the agenda, or is it? :) Thank your for answering.
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 01 Dec 2008 12:12:12 +0100, Robert Osfield <[EMAIL PROTECTED]> a écrit: > Hi Sukender, > > I don't feel this suggestion is appropriate for the OSG. Adaption of > external data structures is a better route that directly integrating > and then using optional compilation to weave a route. > > Robert. > > On Mon, Dec 1, 2008 at 9:59 AM, Sukender <[EMAIL PROTECTED]> wrote: >> Hi Robert, hi everyone, >> >> Abstract (If you don't have time to read all the mail!): Some dependencies >> may be added to OSG when users manually compile OSG with CMake. This would >> be a strictly optional feature that would not be included in precompiled >> packages. Examples: boost ref pointers, boost paths, etc. >> >> >> Detail: >> I know core OSG should not have dependencies other than critical ones, but >> what about *optional* dependencies? >> I explain myself... I mainly think about boost, but this may be applied to >> more. The idea is that some portions of code *may* use dependencies that the >> user chooses while executing the CMake script. But precompiled packackes >> would *NEVER* use such dependencies (or else this would be a custom package). >> >> Take this example: file and directories paths. All methods using paths >> should be written like this: >> void readNodeFile(osg::Path & filePath); >> >> Then, in <osg/Path> header would be found something like: >> #ifdef OSG_USE_BOOST_FILESYSTEM >> >> #include <boost/filesystem/path.hpp> >> namespace osg { >> typedef boost::filesystem::path Path; >> } >> >> #else >> >> #include <string> >> namespace osg { >> typedef std::string Path; >> } >> #endif // OSG_USE_BOOST_FILESYSTEM >> >> >> An option that defines "OSG_USE_BOOST_FILESYSTEM" may then be found in the >> CMake, and should be turned OFF by default (and marked as "advanced"). Of >> course we would also have "BOOST_INCLUDE" and "BOOST_LIB"-like variables, >> created by the FindBoost standard module. >> >> Advantages: >> - Users using use boost::filesystem in their project would benefit from it >> into OSG. >> - It increases the interoperability with other libraries, since the user >> would not have to write method overloads that might create compile errors >> (try calling an osgDB::readNodeFile(boost::filesystem::path &) overload >> giving it a std::string and and you'll get a "ambiguous call" error). >> - Methods using paths would be clearer (as a path is not necessarily a >> string). >> >> Drawbacks: >> - It needs a little tweak in the CMake. >> - Well, I don't see more drawbacks (As this would be a strictly optional >> feature, used and maintained by those who use it). >> >> Other options like these may be included by users that want to use some >> dependencies, such as boost ref pointers (As it has been discussed before). >> These optional features would benefit other users. >> >> About using boost::filesystem, I can write the code and send it to >> osg-submissions. I just wait for authorization. >> >> All users are invited to post suggestions about this! >> Thanks for reading! >> >> Sukender >> PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
