Hi,
Sukender wrote:
Alright then. I guess adopting a kind of Path structure is not on the agenda,
or is it? :)
What exactly do you mean by path structure? Search path?
jp
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
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
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard.
The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for their support.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
