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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
