Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
On Wed, Feb 24, 2010 at 4:45 AM, Robert Osfield robert.osfi...@gmail.com wrote: o Would it be possible to add a Cmake script that we could run that finds the local changed files and reports these to the user and is able to zip these files up into a single package with the approate directory structure still intact? Yes. I believe you could do this with a CMake script which gets run (using cmake -P) when executing a custom target. The CMake script would require the path to command-line svn to be passed to it using -D. It then would run svn status via execute_process() storing the results in a string which it would then need to use a regular expression to match for modified files. It would need to do another execute_process() and call cmake -E tar cz filenames to create a tarball for the files (which does preserve directories). It doesn't look like ZIP files are supported via cmake -E yet. Unfortunately, there are 3 caveats (that I can think of) which make implementing the above of questionable value. 1. The script wouldn't function properly on systems lacking a command-line subversion client (i.e. lets say someone who just has TortoiseSVN installed on Windows). It's possible that support could be added to determine modified files without using the svn command line, although I don't know how this could be accomplished. 2. The script would include ALL modified filenames within the source tree inside the tarball which may or may not be desired. 3. The script would need to be modified if the OSG changed to a different version control system (assuming a change in the patch submission procedure didn't obsolete the need for the script entirely). o Also enabling a user to double graphically check their local modifications relative to svn/trunk or a branch would be very useful. On Linux I use meld . for this within the source directory. Meld is a python diffing tool that uses gtk bindings. It works fairly well and integrates with svn. On Windows I install WinMerge and configure TortoiseSVN to use it as an external diffing tool. TortoiseSVN comes with a graphical diffing tool but it's pretty weak. There is lots more to ponder, and I've tax returns to fill in so I'll leave more thoughts for later. It's too bad there isn't an easy way for all of us developers who donate our personal time from home working on open-source projects to get tax deductions for it. It's charitable work! :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
On Tue, Feb 23, 2010 at 4:32 AM, Tim Moore timoor...@gmail.com wrote: Is there a critical mass of power users willing to use an experimental tree? I'm not sure. Even if not, automated testing of the examples would help verify any OSG tree. How would you go about setting up automatic testing of the examples? What could you test here and how would you do it? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
On Tue, Feb 23, 2010 at 5:40 AM, Robert Osfield robert.osfi...@gmail.com wrote: Hi Tim, I agree with most of your points but would like to clarify a couple of points, add my own two pennies, so I'll be rather savage a cut down your email to key points that I'd to clarify. On Tue, Feb 23, 2010 at 9:32 AM, Tim Moore timoor...@gmail.com wrote: Is there a critical mass of power users willing to use an experimental tree? I don't think an experimental tree will help till we get a better version control system for handling different branches, so even if there is a required critical mass we don't want to unleash it until we have to tools to handle it productively. Even if not, automated testing of the examples would help verify any OSG tree. We are some way there is CDash testing the compile, but having automated testing is one better. Automated testing and OpenGL are not ideal bedfellows so there are various issues there about how do to you can about running the tests and verifying the results. Given the complexities of an developing an automated testing system for OpenGL apps I think we have to put this in a category for future work, it's not something that will see any benefit of in the short term. However, we will see short term benefit in addressing the problems with the present CDash not reporting some build failures. I believe these problems have been resolved and cdash.openscenegraph.org can once again be trusted to report build failures warnings. I've created 4 new nightly builds using our existing build cluster at work. I'd encourage others to do the same and to rely on CTest scripting to configure things the way you want them. I'll try to get some more examples up soon (Cygwin, MinGW, MS Visual Studio). http://cdash.openscenegraph.org/index.php?project=OpenSceneGraph I do all diffs graphically using xxdiff, this I find far more effective than reviewing patches as it gives the complete context of the changes. It's only by reviewing the submission in it's proper context do you get to understand the original code behavior and how it's adapted by the patch. diffs are also unreliable, it's not uncommon for them to fail when you attempt to merge, and if you want to do a graphics diff to do a proper reivew you first have patch a copy then diff between the modified copy and the original. Which is more work. It's these two reasons why I insist on complete files. Robert, I don't think most people read a unified diff and magically absorb all of the changes in their head. Unless it's a trivial patch more often than not I think they just use the patch as a transmittal file. They're going to take that patch and (using a clean source tree checked out from svn) attempt to apply it. Then they're going to use meld, xxdiff, WinMerge, or some other graphical diffing tool to attempt to visualize the changes that have been made between the latest source files and what the user sent in. In this way the patch isn't meant to be all that is needed to understand the changes being made. Rather it is a convenient transmittal format. (submitter) $ svn diff -u changes.diff $ # email changes.diff (reviewer) $ # download changes.diff $ cd clean_trunk $ cat changes.diff |patch -p0 $ meld . As for the occasional patch not applying without errors, I think most open-source projects deal with this just by asking the submitter to generate a new patch against the latest version of the source. Odds are if their patch is against out of date code you're probably not going to want their original source file anyways since you might accidentally revert an unrelated change you have made to the file since. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency andbalance
On Tue, Feb 23, 2010 at 7:02 AM, Tim Moore timoor...@gmail.com wrote: On Tue, Feb 23, 2010 at 12:40 PM, Luc Frauciel luc.frauc...@star-apic.com wrote: How would you go about setting up automatic testing of the examples? What could you test here and how would you do it? -- Philip Lowman Hi, An idea could be to mimic the way VTK handle that question ( http://www.vtk.org) They generate a bunch of reference automatic screenshots through CTest and then do image comparisons. I admit that the initial setup seems quite high but I don't see any other way to do automatic testing of a graphic library. Luc Verifying that they compile and run without a segfault, perhaps using different threading models, would be a good start. Hmm, that doesn't sound too hard to do. The only part I'm not completely clear on is how we could easily make the examples all safely exit after rendering a few frames. Perhaps there is a way to do this with osgviewer command line flags without modifying each example source file? The actual modifications to the build system to allow them all to be run shouldn't be a big deal at all. I think we'd have to add a CMake find_path() call for the OpenSceneGraph-Data folder. We can certainly set whatever environment variables or command line flags we would need to try out the various threading models with each example. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake Structure for new projects
On Mon, Feb 22, 2010 at 7:37 AM, J.P. Delport jpdelp...@csir.co.za wrote: Hi Robert, in our project we have minimum required 2.6.3. I've quickly checked the cmake 2.6.4 source and the FindOpenSceneGraph.cmake module is there at least. Philip Lowman will be able to give more detail I think. Yeah, it's in all releases = 2.6.3. The documentation is pretty self explanatory. If anyone has any issues with it or needs anything added please file a ticket on the CMake bug tracker. Generally email me too because often tickets don't get promptly assigned. http://www.cmake.org/Bug -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Improving the OpenSceneGraph project efficiency and balance
On Tue, Feb 23, 2010 at 1:31 PM, Sergey Kurdakov sergey.fo...@gmail.com wrote: Hi Paul, hi All I have successfully done a few complex branch merges in svn. here is my idea ( keep patient on me, please ) to keep working things as is (Robert controls main branch), but then also have experimental branch ( or branches ) with a volunteer maintainer from community who takes care on keeping branch in sync with current Robert's dev branch. but as well allow in new branch more loose submit code procedure. This will create some double work, but still I think it could be estimated that if Robert has time - he can merge much more code at once, but if he is busy - no one waits for submission - so overall process will speed up. (but from what I see on the net Git supports merging between branches much better than Subversion) so these two versions might be using Git ( not svn as Paul mentions). Sounds like feature branches to me which I think are generally evil and best to be avoided. You inevitably end up with various complete or incomplete features lying around and no easy way to share the changes without merging them up. If git has solved this problem, well maybe feature branches would be slightly more tolerable, but I still think they should be avoided unless necessary. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash reporting is incorrect
On Sat, Feb 13, 2010 at 10:25 AM, Paul Martz pma...@skew-matrix.com wrote: Well, thanks, but I can tell you for certain the build did not complete in 0.3 minutes, so that's another CDash reporting problem that should be investigated and resolved. As I mentioned in another discussion thread, CDash only uses one CPU on my 8-core OS X system and the build takes 35 or 40 minutes to complete. It's clearly doing a full rebuild, so this is not the cause of the missing warnings. Any other ideas? The only other thing I can think of is somehow you're submitting another build with the same name a second time, after the first build is complete. You could try the ctest script idea with a new build name and source directory. Also, there may be ways to extract more detailed information about what ctest is doing, what files it's submitting, etc. I'm not sure how to do this though. The CMake mailing list may be the next place to take this issue. Does this happen with anyone else's builds? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash reporting is incorrect
On Sat, Feb 13, 2010 at 1:11 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Paul, Does this happen with anyone else's builds? I'm pretty sure it's a widespread issue, my builds seem to suffer from the same problems. WHITESTAR and both Skywalker builds on cdash.openscenegraph.org are mine. Yeah I'm seeing this issue too. Guessing this is something messed up with the CDash install or database. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash reporting is incorrect
On Sat, Feb 13, 2010 at 3:48 PM, Philip Lowman phi...@yhbt.com wrote: On Sat, Feb 13, 2010 at 1:11 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Paul, Does this happen with anyone else's builds? I'm pretty sure it's a widespread issue, my builds seem to suffer from the same problems. WHITESTAR and both Skywalker builds on cdash.openscenegraph.org are mine. Yeah I'm seeing this issue too. Guessing this is something messed up with the CDash install or database. Here's my output from the unsuccessful build and the XML submission files are attached which show the build warnings and errors. The dashboard claims everything was peachy: http://cdash.openscenegraph.org/buildSummary.php?buildid=1405 I think the CDash logs need to be examined for obvious signs of errors (corrupted database tables, file permission problems, etc.) Also someone might consider upgrading CDash to the latest version. -- Build files have been written to: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386 ^K Site: sisko Build name: Linux-gcc34-i386 Determine Nightly Start Time Specified time: 00:00:00 CET Create new tag: 20100212-2300 - Nightly Updating the repository Updating the repository: /usr/local/home/lowman/Dashboards/osg/trunk Use SVN repository type Old revision of repository is: 11057 Determine Nightly Start Time Specified time: 00:00:00 CET New revision of repository is: 11057 Gathering version information (one . per revision): Configure project Each . represents 1024 bytes of output . Size of output: 0K Build project Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. .*!... Size: 50K ..**.. Size: 100K ..***. Size: 150K . Size of output: 150K 4 Compiler errors 18 Compiler warnings Test project /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386 Performing coverage Error(s) when building project No tests were found!!! Cannot find any coverage files. Ignoring Coverage request. Create notes file Add file: /usr/local/home/lowman/Dashboards/Configs/osg/Linux-gcc34-i386.cmake Submit files (using http) Using HTTP submit method Drop site:http://cdash.openscenegraph.org/submit.php?project=OpenSceneGraph Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Build.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Configure.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Notes.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Test.xml Uploaded: /usr/local/home/lowman/Dashboards/osg/build.trunk.Linux-gcc34-i386/Testing/20100212-2300/Update.xml Submission successful -- Philip Lowman ctest_submission_logs.tar.gz Description: GNU Zip compressed data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] website down
i get the same errors On Sat, Feb 13, 2010 at 4:32 PM, Michael W. Hall hal...@att.net wrote: Is anyone else having trouble getting to the website? I am getting the following errors: Traceback (most recent call last): File /usr/lib/python2.5/site-packages/trac/web/api.py, line 339, in send_error 'text/html') File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 684, in render_template data = self.populate_data(req, data) File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 592, in populate_data d['chrome'].update(req.chrome) File /usr/lib/python2.5/site-packages/trac/web/api.py, line 168, in __getattr__ value = self.callbacks[name](self) File /usr/lib/python2.5/site-packages/trac/web/chrome.py, line 460, in prepare_request for category, name, text in contributor.get_navigation_items(req): File /usr/lib/python2.5/site-packages/trac/versioncontrol/web_ui/browser.py, line 295, in get_navigation_items if 'BROWSER_VIEW' in req.perm: File /usr/lib/python2.5/site-packages/trac/perm.py, line 523, in has_permission return self._has_permission(action, resource) File /usr/lib/python2.5/site-packages/trac/perm.py, line 537, in _has_permission check_permission(action, perm.username, resource, perm) File /usr/lib/python2.5/site-packages/trac/perm.py, line 424, in check_permission perm) File /usr/lib/python2.5/site-packages/trac/perm.py, line 282, in check_permission get_user_permissions(username) File /usr/lib/python2.5/site-packages/trac/perm.py, line 357, in get_user_permissions for perm in self.store.get_user_permissions(username): File /usr/lib/python2.5/site-packages/trac/perm.py, line 175, in get_user_permissions cursor.execute(SELECT username,action FROM permission) File /usr/lib/python2.5/site-packages/trac/db/util.py, line 51, in execute return self.cursor.execute(sql) File /usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py, line 58, in execute args or []) File /usr/lib/python2.5/site-packages/trac/db/sqlite_backend.py, line 50, in _rollback_on_error return function(self, *args, **kwargs) OperationalError: database is locked Just a FYI. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CDash reporting is incorrect
According to the dashboard your build completed in 0.3 minutes. My guess is you're not make cleaning the build before kicking off the Nightly target so the warnings aren't showing up unless that particular source file gets recompiled. Your best bet is probably to create a CTest script and use ctest -S foo.cmake to kick off your builds. It will run CMake configuring from scratch, build the code and then run ctest and submit all of the results. See: http://www.itk.org/Wiki/CMake_Scripting_Of_CTest be sure to include the following line for a clean build every night: set(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE) On Fri, Feb 12, 2010 at 7:05 PM, Paul Martz pma...@skew-matrix.com wrote: Hi all -- I routinely get harmless warnings with my OSG build on OS X. I've set up the system (MotorCity) for nightly reporting, but the CDash web page never shows the warning. http://cdash.openscenegraph.org/index.php?project=OpenSceneGraph I know the warnings are occurring in the nightly build because I see * asterisks in the console output during the build. But when the results appear on the CDash web page, it shows my build had 0 warnings. Does anyone know what might be amiss here? -- Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Visual Studio 9 2008 3rd Party
On Sat, Feb 6, 2010 at 8:43 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Luigi, What about having a repo of working recipes where people who have the itch and have successfully scratched can share the recipe in a somehow formalized way. In my previous mail, I' m suggesting use of Cmake external projects as a way to formalize download,unpack,patch,configure,make and install we could also think for simple plugins, some high level read-write testing based on osgconv. Yes, I agree with the principle of CMakePorts. It seemed promising about a year ago when it was announced, has any progress been made since then? Seems to me it has always built the same small list of dependencies, no more... Of course, if people don't get involved, it won't progress. So I would second your suggestion to Adrian that he somehow contribute to that instead of making / asking for binaries. It'll profit more people if he does that. I haven't made as much progress as I have wanted. I have submitted work upstream, however, and both zlib libpng now have CMakeLists.txt in their trunks (libpng has made a release with it, zlib has not). I did some integration work a while back with CMakePorts and OSG but I didn't finish everything I had wanted so I didn't submit the work to osg-submissions. I hope to get back to this work at some point. The add external project stuff for CMake sounds pretty cool. I haven't looked at it much. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fix for osgPPU FindOSG.cmake; lack of svn properties
If anyone is interested, you can also check out FindOpenSceneGraph.cmake
which is part of CMake now. It does debug/release libraries and version
support.
On Dec 10, 2009 3:30 PM, Paul Martz pma...@skew-matrix.com wrote:
Try this one instead; I forgot that CMake can't handle backslashes.
Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_
http://www.skew-matrix.com/ +1 ...
Paul Martz wrote:
Hi Art -- I've modified the FindOSG.cmake script so that it looks in MS
Windows standard OSG ins...
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
# This module defines
# OSG_LIBRARY
# OSG_FOUND, if false, do not try to link to osg
# OSG_INCLUDE_DIRS, where to find the headers
# OSG_INCLUDE_DIR, where to find the source headers
# OSG_GEN_INCLUDE_DIR, where to find the generated headers
# to use this module, set variables to point to the osg build
# directory, and source directory, respectively
# OSGDIR or OSG_SOURCE_DIR: osg source directory, typically OpenSceneGraph
# OSG_DIR or OSG_BUILD_DIR: osg build directory, place in which you've
#built osg via cmake
# Header files are presumed to be included like
# #include osg/PositionAttitudeTransform
# #include osgUtil/SceneView
## headers ##
SET( CMAKE_DEBUG_POSTFIX d )
MACRO( FIND_OSG_INCLUDE THIS_OSG_INCLUDE_DIR THIS_OSG_INCLUDE_FILE )
# configure matched pair of include / library search paths
SET( OSG_SEARCH_PATHS
$ENV{OSG_SOURCE_DIR}
$ENV{OSG_BUILD_DIR}
${OSGDIR}
$ENV{OSGDIR}
${OSG_DIR}
$ENV{OSG_DIR}
${OSG_ROOT}
$ENV{OSG_ROOT}
${OSG_ROOT_DEBUG}
$ENV{OSG_ROOT_DEBUG}
${CMAKE_INSTALL_PREFIX}
${CMAKE_PREFIX_PATH}
/usr/local
/usr/local/lib64
/usr
/sw # Fink
/opt/local # DarwinPorts
/opt/csw # Blastwave
/opt
/usr/freeware
[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session\
Manager\\Environment;OSG_ROOT]/
~/Library/Frameworks
/Library/Frameworks
C:/Program Files/OpenSceneGraph
C:/Program Files (x86)/OpenSceneGraph
)
FIND_PATH( ${THIS_OSG_INCLUDE_DIR} ${THIS_OSG_INCLUDE_FILE}
PATHS ${OSG_SEARCH_PATHS}
PATH_SUFFIXES include build/include Build/include
)
ENDMACRO(FIND_OSG_INCLUDE THIS_OSG_INCLUDE_DIR THIS_OSG_INCLUDE_FILE)
#FIND_OSG_INCLUDE( OSG_GEN_INCLUDE_DIR osg/Config )
FIND_OSG_INCLUDE( OSG_INCLUDE_DIR osg/Node )
## libraries ##
MACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
FIND_LIBRARY(${MYLIBRARY}
NAMES ${MYLIBRARYNAME}
PATHS ${OSG_SEARCH_PATHS}
PATH_SUFFIXES lib build/lib Build/lib
)
ENDMACRO(FIND_OSG_LIBRARY MYLIBRARY MYLIBRARYNAME)
SET( TMP_LIBRARY_LIST
OpenThreads osg osgGA osgUtil osgDB osgText osgViewer )
FOREACH(LIBRARY ${TMP_LIBRARY_LIST})
STRING( TOUPPER ${LIBRARY} UPPPERLIBRARY )
FIND_OSG_LIBRARY( ${UPPPERLIBRARY}_LIBRARY_RELEASE ${LIBRARY} )
FIND_OSG_LIBRARY( ${UPPPERLIBRARY}_LIBRARY_DEBUG
${LIBRARY}${CMAKE_DEBUG_POSTFIX} )
LIST( APPEND OSG_LIBRARIES debug ${${UPPPERLIBRARY}_LIBRARY_DEBUG}
optimized ${${UPPPERLIBRARY}_LIBRARY_RELEASE} )
ENDFOREACH(LIBRARY ${TMP_LIBRARY_LIST})
SET( OSG_FOUND NO )
#IF(OSG_LIBRARY_RELEASE OR OSG_LIBRARY_DEBUG AND OSG_INCLUDE_DIR AND
OSG_GEN_INCLUDE_DIR)
#SET( OSG_FOUND YES )
#SET( OSG_INCLUDE_DIRS ${OSG_INCLUDE_DIR} ${OSG_GEN_INCLUDE_DIR} )
#GET_FILENAME_COMPONENT( OSG_LIBRARY_DIR_RELEASE ${OSG_LIBRARY_RELEASE}
PATH )
#GET_FILENAME_COMPONENT( OSG_LIBRARY_DIR_DEBUG ${OSG_LIBRARY_DEBUG}
PATH )
#SET( OSG_LIBRARY_DIRS ${OSG_LIBRARY_DIR_RELEASE}
${OSG_LIBRARY_DIR_DEBUG} )
#ENDIF(OSG_LIBRARY_RELEASE OR OSG_LIBRARY_DEBUG AND OSG_INCLUDE_DIR AND
OSG_GEN_INCLUDE_DIR)
IF(OSG_LIBRARY_RELEASE OR OSG_LIBRARY_DEBUG AND OSG_INCLUDE_DIR)
SET( OSG_FOUND YES )
SET( OSG_INCLUDE_DIRS ${OSG_INCLUDE_DIR} )
GET_FILENAME_COMPONENT( OSG_LIBRARY_DIR_RELEASE ${OSG_LIBRARY_RELEASE}
PATH )
GET_FILENAME_COMPONENT( OSG_LIBRARY_DIR_DEBUG ${OSG_LIBRARY_DEBUG}
PATH )
SET( OSG_LIBRARY_DIRS ${OSG_LIBRARY_DIR_RELEASE} ${OSG_LIBRARY_DIR_DEBUG}
)
ENDIF(OSG_LIBRARY_RELEASE OR OSG_LIBRARY_DEBUG AND OSG_INCLUDE_DIR)
___
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
Re: [osg-users] SO version inconsistency
Robert, Until the XCode files can be removed I would recommend simply substituting version numbers in by hand. Also, is there a list of what's holding up switching to CMake in regards to XCode support? On Thu, Nov 19, 2009 at 10:31 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Alberto, On Thu, Nov 19, 2009 at 2:42 PM, Alberto Luaces alua...@udc.es wrote: I think we should remove Version, because things are not working now. What it is getting installed is the old Version file. I did the test of modifying it with some incorrect values and I could verify that those values were present on the file copied by the installation process. Are you talking about an out of source build here? An in source build certainly works from the testing I've done, but I haven't tested an out of source build yet. IMHO the fixes would be either to remove Version and put the output of the configured Version.in in its place, PROJECT_SOURCE_DIR, as my snippet showed, or to write an install rule to copy the configured Version.in after the build from the binary directory. Removing Version from include/osg/Version would break the hand maintained XCode projects, and force it to have it's own local copy of Version which would be a backwards step all round. So if we remove Version then we really have to kick the XCode projects to touch as well. Assuming the problem you are seeing is down to an out of source build then the short term solution is the simple change the location that the autogenerated Version to be place in the PROJECT_SOURCE_DIR. You've never said it explictly but I presume you mean this to get rout the out of source build issue. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
You might want to check svn because I filed a bug about the lack of BulletMultiThreaded on x86_64 causing a few build errors in various places in the source code several months ago and recently they closed the report saying BulletMultiThreaded now builds on x86_64. On Wed, Nov 11, 2009 at 6:49 AM, Alberto Luaces alua...@udc.es wrote: Hi Paul, Lovely work! I assume that for now, independent threading for the physics is handled only by the multi-threaded Bullet library, is this correct? I couldn't find in the source any place using the PhysicsThreading class, are you going to use it in the future? I couldn't be able to compile the library since Bullet disables the building of the BulletMultiThreaded library on 64 bit environments, being it a requirement for osgBullet. Regards, Alberto Paul Martz writes: Hi all -- I'm pleased to announce two new open source OSG-based projects, osgWorks and osgBullet, licensed under LGPL. These are active projects with discussion groups, source downloads, wiki, and issue tracking. They are actively used by the open source VE-Suite application. They were funded by Ames Laboratory and created primarily by myself / Skew Matrix Software. osgWorks is a set of applications and software tools useful to OSG software developers. It features a set of command line analysis tools, a library with utility functions and NodeVisitors for things like screen capture, scene graph comparison, and polygon decimation, and plugins to support .OSG and hierarchical structure storage. For more information on osgWorks and to download the source, visit: http://osgworks.vesuite.org osgBullet is a set of software tools for applications that use both OSG and the Bullet physics library. It features utilities to create Bullet collision shapes from OSG data and vice versa, run the physics simulation in a separate host thread, debug utilities to display Bullet collision shapes in an OSG scene, support for arbitrary scaling and center of mass, and support for COLLADA. For more information on osgBullet and to download the source, visit: http://osgbullet.vesuite.org For questions, please either post here or to the project discussion groups hosted on Google Groups. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
Was using the CMake build but am not tracking svn at the moment. Perhaps this thread will help? bulletphysics.org/Bullet/phpBB3/viewtopic.php?t=4238 On Nov 11, 2009 8:36 AM, Alberto Luaces alua...@udc.es wrote: Hi Philip, what build system are you using? The most recent svn version of Bullet says in src/CMakeLists.txt: $ head CMakeLists.txt if (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletSoftBody BulletCollision BulletDynamics LinearMath ) else (CMAKE_SIZEOF_VOID_P MATCHES 8) SUBDIRS( BulletMultiThreaded BulletSoftBody BulletCollision BulletDynamics LinearMath ) endif (CMAKE_SIZEOF_VOID_P MATCHES 8) Regards, Alberto Philip Lowman writes: You might want to check svn because I filed a bug about the lack of Bullet... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Announcing osgWorks and osgBullet
The response to my bug report must have been completely wrong then... Guess I should check the source before I post. Like I said, am not tracking svn bullet at the moment. http://tiny.cc/Eoa3l On Nov 11, 2009 10:00 AM, Alberto Luaces alua...@udc.es wrote: Definitely there is no support for BulletMultiThreaded in 64 bits at the moment. From the last post in the forum thread you gave to me: BulletMultiThreaded, MultiThreadedDemo, Gpu2dDemo, Gpu3dDemo are not supported on 64bit platforms. It was accidently enabled in a previous revision, but now it has been disabled in the trunk. If you can make any of this work on 64 platforms, please consider contributing it. Regards, Alberto Philip Lowman writes: Was using the CMake build but am not tracking svn at the moment. Perhaps this thread will help? ... On Nov 11, 2009 8:36 AM, Alberto Luaces wrote: Hi Philip, what build... ___ osg-users mailing list osg-us...@lists.openscenegrap... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Would someone be willing to help me diagnose a performance issue?
Slowly minimize the differences between the slow machine and the fast machine until the problem goes away. When it does, you have isolated the problem. Also bear in mind it could be the machine itself (hardware, drivers, etc.) On Nov 10, 2009 12:42 PM, Frank Sullivan knarf.navil...@gmail.com wrote: Hello, I have two applications, both of which are displaying basically the same scene. One application runs at 230+ fps while the other runs at about 45 fps. I'm trying to figure out what is causing this performance difference. Using high-precision timers, I've been able to determine that the difference occurs somewhere in the rendering of the scene graph, but I'm not 100% sure where. I have a couple of ideas, but each will take some amount of time to investigate, and so I was hoping someone might be able to lead me towards the most-correct answer. The first idea I had concerns differences in how the scene graphs are structured in each application. The quick app works simply by loading the three models that it needs (from FLT files, so these 'models' are in fact complex sub-graphs) and attaches them to the root node, and sets that root node as the scene data. The slow app loads every model that could possibly ever be used (52 in all, and again each 'model' could actually be a complex sub-graph). These 52 nodes are then attached to the root, and their visibility is turned off by setting their node mask to 0. Then, if the user of the application wants to see a model, the app will copy the node (and all of it's children) and then add this copy to the scene root group, with the visibility turned on. This way, if the user of the app wants to populate the scene with many instances of the same model, they can do so, because each time they do it, a separate copy of the node is made. I realize that there are a lot of things that can be done to make the slow app more memory-efficient. For instance, it could use lazy loading to load a model only when it is needed (although this may cause a noticeable delay, but that would probably be fine). And if the user wants to see several instances of this model, this could be accomplished without copying the model's entire subgraph. Instead, we could simply create a new matrix transform, and add THAT to the root, and add the model's node as a child of this new matrix transform (at which point, the model's node will have more than one Matrix Transform parent). However, these issues seem to pertain more towards memory efficiency than rendering efficiency, so I'm not sure if this is going to solve my immediate problem (although it is almost certainly something I will implement later on). Related to this, I was wondering if anyone had an explanation as to what the Camera / View statistics referred to. I read the Quick Start Guide, and it had excellent information about the Event/Update/Cull/Draw/GPU chart at the top of the statistics screen, but I'm not exactly sure what the statistics in the Camera / View windows refer to. For instance, does the Vertices stat refer to the total number of vertices in all of the drawables, whether those drawables are visible or not? The reason I ask is that, in terms of these statistics, both the Quick App and the Slow App have nearly-identical numbers in the View section, but in the Camera section, the Slow App's numbers are way, way, way higher. I wonder if this tells me something about how to optimize the Slow App to bring it up to speed. The other major difference I noticed was in the threading model. The Quick App uses DrawThreadPerContext and the Slow App uses SingleThreaded. I tried getting the slow app to use DrawThreadPerContext by setting the environment variable, but it ignored that value and chose the SingleThreaded model for me. I can probably figure out why this happens, but I'm curious to know if you think this will affect performance much? Thanks so much to whomever has patience to read all this! Frank -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=19436#19436 ___ 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
Re: [osg-users] Floating point image I/O in OSG
I think things will get a lot easier for people when I submit the Cmakeports support I mentioned in a thread a while back. It can automatically build zlib alongside the OSG (without including zlib in the source tree). On Oct 13, 2009 2:21 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Art, However, I have never tested if the plugin will also work under windows, because it depends on Z... Just FYI, zlib is normally included in the 3rd party packages by default, since for example libpng and a few of OSG's own plugins depend on it. So modulo a few tweaks here and there, it should build for Windows just fine. If it's useful to a group of people perhaps it could be included in OSG? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-us...@lists.openscenegra... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG viewer blocks Qt window
Can you post a small example of the problem? I've been using Qt with OSG for about a month now and haven't run into anything like this. Have you considered using something like a QTimer to send your keep-alive messages instead? On Mon, Sep 14, 2009 at 9:40 AM, Zoe Catz small_dra...@gmx.net wrote: Hi, I've written a Qt application. It's used to configure some settings which should be considered it my visualisation later on. In addition, this window update handles sending keep-alive messages via UDP in the background. The visualisation itselft should be rendered in an own window by OSG. The problem is, as soon as I add the osg window the qt window incl. the UDP packages are not updated/sent anymore. So my question is, how can I force both (qt and osg) windows to update? Thank you in advance! Cheers, grisu -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17338#17338 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate example solution with osg Examples
On Fri, Sep 4, 2009 at 10:56 AM, Philip Lowman phi...@yhbt.com wrote:
I would suggest first make installing OSG somewhere. Then create a small
CMakeLists.txt file that uses the FindOpenSceneGraph.cmake that is released
with CMake 2.6.4 (see example in file).
It should be quite easy to make most of the examples compile outside of the
OSG's build system. For those with external dependencies like SDL or QT it
will take a bit more work.
Now that I'm in front of an actual keyboard, here's an example
CMakeLists.txt that builds osgteapot.
=
project(Foo)
cmake_minimum_required(VERSION 2.6.2)
find_package(OpenGL REQUIRED)
include_directories(${OPENGL_INCLUDE_DIR})
find_package(OpenSceneGraph REQUIRED osgDB osgViewer)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(osgteapot osgteapot.cpp)
target_link_libraries(osgteapot
${OPENSCENEGRAPH_LIBRARIES}
${OPENGL_LIBRARIES})
=
.. Original Message ...
On Fri, 4 Sep 2009 11:08:36 +0200 Filip Holm filip.h...@gmail.com
wrote:
Hi All,
Is there a way to generate a solution that only contains the osg
Example projects with the current CMakeLists.txt configuration?
I've looked through the mailing list and the CMakeLIst files without
finding an answer. I'm working on MSVC80 and find that a solution
containing all the osg Core projects, applications and examples is a
bit cumbersome to work with.
I don't have a hole lot experience with CMake yet, but if there are no
objections, I might have wack at setting up the CMakeLists to support
a standalone example project.
Filip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Philip Lowman
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate example solution with osg Examples
On Sat, Sep 5, 2009 at 11:20 AM, Philip Lowman phi...@yhbt.com wrote: cmake_minimum_required(VERSION 2.6.2) Woops. This should be VERSION 2.6.3 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Generate example solution with osg Examples
I would suggest first make installing OSG somewhere. Then create a small CMakeLists.txt file that uses the FindOpenSceneGraph.cmake that is released with CMake 2.6.4 (see example in file). It should be quite easy to make most of the examples compile outside of the OSG's build system. For those with external dependencies like SDL or QT it will take a bit more work. .. Original Message ... On Fri, 4 Sep 2009 11:08:36 +0200 Filip Holm filip.h...@gmail.com wrote: Hi All, Is there a way to generate a solution that only contains the osg Example projects with the current CMakeLists.txt configuration? I've looked through the mailing list and the CMakeLIst files without finding an answer. I'm working on MSVC80 and find that a solution containing all the osg Core projects, applications and examples is a bit cumbersome to work with. I don't have a hole lot experience with CMake yet, but if there are no objections, I might have wack at setting up the CMakeLists to support a standalone example project. Filip ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Inconsistent dll linkage
On Tue, Sep 1, 2009 at 10:39 AM, Paul Martz pma...@skew-matrix.com wrote: Philip Lowman wrote: You're getting a warning because DoomLikeManipulator is missing declspec declarations but publicly inheriting from a class that has them. See the definition of OSGGA_EXPORT in include/osgGA/Export and do something similar for your code, perhaps KILLINGSPREE_EXPORT. Oh wait, that's Unreal Tournament. :) Wouldn't this only be necessary if he were making a DLL? If he's just making an executable, then his own custom manipulator shouldn't need declespec. In fact, I'll guess that he has used the osgGA's export declaration in his own manipulator class, which would certainly be a bug in his code and easy to fix. Without seeing the code, though, it's hard to tell. Paul, I think you're right because I just tried something similar and that seems to be the easiest way to reproduce this warning. I think I had this confused with another problem I had once. Sorry for the noise. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
On Mon, Aug 31, 2009 at 4:43 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Philip, I'm all for integrating CMakePorts support into OSG build. I'm I correct in reading the cmakeports_osg.path that one would build the OSG and have the external libs build automatically when required? Currently .patch only lists jpeg, zlib and png. Is this just a preliminary lists? Are others pending? Hi Robert, The way it is setup now you would enable an option and then pick the directory where the ports exist on your system, then it would find any that exist in the directory and build them if present. I do not have it setup so that it would try to build the port if you don't already have the dependency but this is an interesting idea. First I would have to determine a safe way for Find3rdPartyDependencies.cmake and CMakePortsSearch.cmake to interact with each other which currently does not exist. Yes, only libjpeg, libpng, and zlib have been made available for the moment. freetype glut have been done but need packaging/testing. I also plan to ensure this works for curl and tiff. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Inconsistent dll linkage
On Mon, Aug 31, 2009 at 8:14 PM, Alex Malhao franciskovi...@gmail.comwrote:
Hi,
Now my osgviewer.cpp is working fine. However when I add one other code the
following error is:
[code]
-- Rebuild All started: Project: OSGDefaultProject, Configuration:
Release Win32 --
Deleting intermediate and output files for project 'OSGDefaultProject',
configuration 'Release|Win32'
Compiling...
DoomLikeManipulator.cpp
.\DoomLikeManipulator.cpp(28) : warning C4273:
'osgGA::DoomLikeManipulator::DoomLikeManipulator' : inconsistent dll linkage
c:\osg\osgdefaultproject\osgdefaultproject\DoomLikeManipulator.h(56)
: see previous definition of '{ctor}'
Do I need to do anything more than just add the DoomLikeManipulator.h?
You're getting a warning because DoomLikeManipulator is missing declspec
declarations but publicly inheriting from a class that has them. See the
definition of OSGGA_EXPORT in include/osgGA/Export and do something similar
for your code, perhaps KILLINGSPREE_EXPORT. Oh wait, that's Unreal
Tournament. :)
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Rethinking 3rd party dependencies?
On Sat, Aug 29, 2009 at 9:03 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Philip, I like your idea of making CMake setups for these dependencies, it kind of resembles automake/autoconf. The problem is that the CMake files won't be managed by the upstream project, but by another external group (us). Won't the same problem happen when we decide to change versions? This is a good point. I think the plan is to submit the CMakeLists.txt to the upstream project for them to manage (should they choose to). libpng betas at least now have CMakeLists.txt, for example. But I concede that we (whoever volunteers on the CMakePorts project) will have to maintain some of the CMakeLists.txt files, but this should hopefully be a fairly minor effort. Each CMakePort does have a maintainer as well who should be subscribed to the project on freshmeat or an announce list. http://code.google.com/p/cmakeports/wiki/AvailablePorts Maybe I'm over-evaluating the risk, since the version will likely be bumped only seldom and when it is, only one person will have to check that everything still builds correctly and fix it if it doesn't, and then commit the changes to the CMake files for everyone to use. But still, I wouldn't want to be that person. Luckily most of these projects are ABI/API stable so changes to OSG should be in theory non-existent. Changes to the CMakeLists.txt to build them will be required, but I suspect that they will be relatively minor. Anyways, that's my 2 cents on the subject, I like the idea but it carries some risks, we just have to be aware before we decide to support this completely... Yes, I agree. It probably should be an experimental thing if we decide to try it out and certainly would be disabled by default. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rethinking 3rd party dependencies?
While poring over thread after thread dealing with build dependencies on Windows I had a weird thought a while back: computers are fast these days, why not just build everything (including 3rd party dependencies) from source? The way I see it, issues on Windows are going to get worse far before they get any better. Issues like: 1. Differing compiler versions (MSVC 7.1/8/9, MinGW 3.4/4.4) 2. The need for Debug libraries with certain compilers 3. The need for 32 and/or 64-bit libraries 4. The occasional need for a complete static build 5. The need/desire for some people to compile with /MT or _SECURE_SCL=0 on MSVC ...are likely not to be going away anytime soon and they can create a confusing ecosystem. Also, security issues library bugfixes tend to get ignored once someone has that prebuilt library sitting off in CM somewhere. So I cmakeified libpng, zlib, and libjpeg (building on some work previously done by Luigi Calori and others) and wrapped them in ZIP files called CMakeports. The three put together take about 5 seconds total to build on my 3 year old core2 duo. They are available at the website below. http://code.google.com/p/cmakeports/ I've integrated and tested* the 3 ports with OSG using osgviewer --image, and things seem to be working fine. I'd like to submit this to osg-submissions assuming there is enough interest in the idea. I'm doubtful this could satisfy 100% of the dependencies people might want to use with the OSG, but I'm optimistic it could cover the major ones (png, jpg, zlib, tiff, freetype seem like no-brainers to me). * I have tested: MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=ON (Debug Release) MinGW 3.4. * I have partially tested: MSVC9 32-bit DYNAMIC_OPENSCENEGRAPH=OFF (code compiles but haven't tried building/linking a custom viewer) * I have not tested: MSVC8 MSVC9 64-bit MinGW 4.4.0 -- Philip Lowman cmakeports_osg.patch Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg DIS (Distributed Interactive Simulation)
Also check out KDIS. On Tue, Aug 25, 2009 at 8:11 AM, Trajce Nikolov nikolov.tra...@gmail.comwrote: OpenDIS looks good. Wasn't aware of it. Thanks for all the feedback Nick On Tue, Aug 25, 2009 at 2:04 PM, Ralf Stokholm alfma...@arenalogic.comwrote: Hi All If you need a distributed simulation based on OSG I can recommend Delta3d which has already integrated HLA RPRFOM (works with RTI-s MÄK Pitch Portico and CERTI) and also DIS based on OpenDIS. Brgs. Ralf Stokholm Arenalogic www.arenalogic.com 2009/8/25 Tomlinson, Gordon gtomlin...@overwatch.textron.com And don't forget HLA :) ( http://en.wikipedia.org/wiki/High_Level_Architecture_(simulationhttp://en.wikipedia.org/wiki/High_Level_Architecture_%28simulation)) as this has depreicated DIS for many :) *Gordon Product Manager 3d *__ *Gordon Tomlinson **Email * : gtomlinson @ overwatch.textron.com __ -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Maxim Gammer *Sent:* Tuesday, August 25, 2009 5:57 AM *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] osg DIS (Distributed Interactive Simulation) Hi, what's wrong with CERTI or PORTICO? 2009/8/25 Trajce Nikolov nikolov.tra...@gmail.com Hello community, are you interested in opensource crossplatform DIS library? cheers, Nick http://www.linkedin.com/in/tnikolov Sent from Benoni, Gauteng, South Africa ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Maxim Gammer ___ 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 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osg-submissions] CDash site now under openscenegraph.org
On Thu, Jul 23, 2009 at 9:38 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: So, let's start submitting builds again people! :-) Thanks to you and Jose for setting this up. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Unit tests
On Fri, Jul 17, 2009 at 7:49 AM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, For our osg-based project, I am searching for unit tests. Visual Studio implement them only in managed c++, so I am looking at different libs to do that. I just tried googleTest, but it needs a /MT compilation instead of osg needs a /MD ... Just modify the project files that come with gtest to build with /MD /MDd. It should work fine. 1. Open up solution file 2. Use CTRL+Click to select all gtest projects 3. Right click and go to Properties 4. Expand Configuration Properties-C/C++-Code Generation 5. While modifying Configuration Active(Release) choose Multi-threaded DLL (/MD) from the Runtime Library option. 6. Switch Configuration to Active(Debug) and choose Multi-threaded Debug DLL (/MDd) from the Runtime Library option. 7. Build -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.2 release candidate three tagged
On Tue, Jul 14, 2009 at 9:10 PM, Pierre BOURDIN bour...@imerir.com wrote: Hi, 2009/7/14 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com: Hi Robert, I have spotted that CDash is not working as usual. I have no clue as to why or what to do about it as I'm the not the one that set this up or has knowledge of how to administer it. Ah ha! Logging in with my user account on the CDash site to answer Pierre's question, I noticed this message: * The project OpenSceneGraph has reached the maximum number of builds. You should upgrade to a premium account to avoid missing builds.[Upgrade Now] (http://www.kitware.com/products/cdashpro.html) That's interesting. I noticed the CDashPro thing a few months back. I thought it only limited the number of nightly builds not the total number of builds allowed, though. I guess that means that either we need to pay for a premium account (silver is 16$/month, 49$/3months, 189$/year), or host our build results on the openscenegraph.org site somehow (if that's possible). Anyone know about this? No idea, but installing a CDash server doesn't look very difficult as far as I see the doc: http://public.kitware.com/Wiki/CDash:Installation It just require some usual libs on the server and a database... It could be interesting to try ? I would recommend that Jose Luis simply install CDash somewhere on openscenegraph.org if possible. The install is fairly simple for a PHP/MySQL webapp and I would be happy to lend assistance with setup or ongoing maintenance if needed. I'm assuming here that OpenSceneGraph like most OS projects is running on a shoestring budget and paying for CDashPro is not feasible. All things being equal, $189/year is probably pretty comparable to what it would cost to administer your own installation of CDash for a year just in labor alone (factoring in installation, upgrades, database purges, unexpected issues, etc.). -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cygwin Compile Question OSG 2.8.1
On Mon, Jun 8, 2009 at 8:54 PM, Christopher Wang cwang7...@hotmail.comwrote: Hi, I did, I installed free glut. I got a small opengl program compiling. Perhaps something is missing from the configure script? ... I don't really use Cygwin much but I do have it installed here. Could you try the following... Instead of configure type $ ccmake --version (and tell us the version... then run) $ ccmake . Hit c to configure Hit t to toggle advanced mode Search down until you find OPENGL_INCLUDE_DIR, OPENGL_gl_LIBRARY, and OPENGL_glu_LIBRARY. What are their values? Mine are (respectively): /usr/include/w32api /usr/lib/w32api/libopengl32.a /usr/lib/w32api/libglu32.a -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
On Sun, Jun 7, 2009 at 3:40 AM, Jason Daly jd...@ist.ucf.edu wrote: Oh, boy. Where to begin. First of all, I don't have a clue how this discussion got out of hand. We started out with a simple issue that showed up on a CentOS box. It couldn't compile the recently released OSG 2.8.1 version. The issue came down to the fact that CentOS and Red Hat Enterprise Linux only have a 2.4.5 binary version available. There was friction between the community that said to just upgrade to 2.6, and the CentOS users and administrators that tried to explain that it is difficult to do that in a large enterprise environment. I jumped into this thread to try and help both parties understand the needs of the other. Instead of a calm resolution, I've now been subjected to a rant from the OSG czar who says I need to contribute more. I stopped reading about here. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
On Fri, Jun 5, 2009 at 4:36 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Paul, On Thu, Jun 4, 2009 at 8:11 PM, Paul Melisosg-us...@assumetheposition.nl wrote: First, try this: In applications/osgversion/CMakeLists.txt change ENDIF() to ENDIF(OSG_MAINTAINER) That line looks fishy. Cmake used to require the the IF() ENDIF() matched but this requirement was dropped, and now the OSG-2.9.x and svn/trunk has been cleaned up to not have the matching entries as it makes the code far more readable and maintainable. I was under the impression that this wouldn't cause too many problems except for really old CMake versions. Here's the problem that caused the configure warning. The variable below (which is on the first line in the trunk's CMakeLists.txt) would need to be added to the OpenSceneGraph-2.8.0 branch if we wanted to take advantage of unmatched if/endif in that branch. This change on the trunk came in r9908 and wasn't applied to the 2.8 branch. set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS TRUE) This allows the unmatched if/else/endif to work on CMake 2.4.4-2.4.8. The variable is not needed in CMake 2.6 as it automatically supports the feature. The change in r10313 does fix the warning. To prevent this warning from cropping up again I would suggest either applying r9908 to the 2.8 branch or be very careful backporting CMakeLists.txt files and changes from the trunk to the OpenSceneGraph-2.8 branch since they all no longer have matching else/endif constructs. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] build errors with 2.8.1
On Fri, Jun 5, 2009 at 11:38 AM, John Kelso ke...@nist.gov wrote: Hi, I'm a bit surprised by this because as far as I know we have a fairly recent version of Centos. Are there no other Centos users out there trying 2.8.1? cat /etc/redhat-release CentOS release 5.3 (Final) which incudes this version of cmake: rpm -q cmake cmake-2.4.8-3.el5.i386 Is cmake-2.4.8 really old? That said, I'll try to get our system guy to install a newer version of cmake. Thanks again, CMake 2.4.8 isn't really old but many people have switched to 2.6.x because of the new features present in it and also because 2.4.x is no longer being maintained. You can always run CMake out of your home directory without bothering your systems guy. There are prebuilt versions of it for Linux available here. http://www.cmake.org/cmake/resources/software.html -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] removal of OSG specific environment variables from find modules
On Thu, May 14, 2009 at 10:10 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Does anyone depend on the OSG_ROOT, OSGDIR, and OSG_DIR environment and/or registry session variables in the non-OSG related CMake find modules in CMakeModules? I don't think so, it would be a bit weird wouldn't it? What was the rationale in using those in those modules in the first place? I'm guessing it's just copy-and-paste from already existing find modules. The only other explanation is it was intentional, to pick up the import libraries distributed with the OSG 2.2/2.4 installer. This seems awfully dangerous to me (if this even works at all still for VS8 users) so I'll be submitting the fix to osg-submissions shortly. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] removal of OSG specific environment variables from find modules
Hi all, Does anyone depend on the OSG_ROOT, OSGDIR, and OSG_DIR environment and/or registry session variables in the non-OSG related CMake find modules in CMakeModules? Are there any objections to removing these variables? FindCOLLADA.cmake FindFFmpeg.cmake FindFLTK.cmake etc. If you have the old OSG 2.2/2.4 binary package installed, these find modules end up detecting libraries within C:\Program Files\OpenSceneGraph. This is rather annoying when configuring a MinGW build and could cause weird errors on newer builds of the OSG as well as dependencies, compilers, etc. are updated. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] SDL no longer builds
I can't replicate the SDL problems (and haven't tried the other ones). After enabling BUILD_OSG_EXAMPLES in ccmake I have the following values for the SDL visible under the advanced section of the cache: SDLMAIN_LIBRARY */usr/lib/libSDLmain.a SDL_INCLUDE_DIR */usr/include/SDL SDL_LIBRARY */usr/lib/libSDLmain.a;/usr/lib/libSDL.so;-lpthread osgviewerSDL.o compiles just fine. This is with CMake 2.6.2 and the libsdl1.2-dev package installed on Ubuntu 9.04 What version of CMake are you using? Can you include some more details? On Wed, May 6, 2009 at 4:43 PM, Francois Genolini fgenol...@hotmail.comwrote: Hi, Ubuntu Linux 9.04, latest svn (6th May 2009) cmake-gui to enable all features (including SDL, ffmpeg, wxwidgets, etc...) to generate CodeBlocks Makefiles SDL does not compile (#include SDL.h instead of #include SDL/SDL.h) even if the correct include path is specified in cmake adding a manual CFLAGS and CXXFLAGS to have -I/usr/include/SDL fixes the compiling Link however does not work because linking of the present3d application omits to include -lSDL in the Makefile Manual modification of Makefile and link.txt allows app to build ffmpeg also requires a lot of manual modifications (here again #include swscale.h is used instead of the correct #include libswscale/swscale.h). Manual specification of all include folders in cmake-gui allows build (strange that cmake finds ffmpeg but does not configure the CMakeFiles correctly for actual valid OSG compile). wx does not build either, here again hacking gets through ... Thank you! Cheers, Francois Genolini Aberdeen, Scotland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=11558#11558 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Build problem with gdk-x11-2.0
On Wed, May 6, 2009 at 12:33 PM, Davin da...@appliomics.com wrote: I do not know if POPPLER_LIB_DIRS should be replaced with POPPLER_LIBRARY_DIRS, but I hope the above proves helpful. Yes that looks like a simple typo. Replacing POPPLER_LIB_DIRS with POPPLER_LIBRARY_DIRS should fix your problem (can you confirm that?). Apparantly not a lot of people build this plugin without it being located in /usr/lib otherwise someone would have caught this earlier. What you're seeing is the result of a function call into CMake's FindPkgConfig module made in the root CMakeLists.txt of OSG (search for POPPLER). The function provides PACKAGE_LIBRARY_DIRS: http://www.cmake.org/cmake/help/cmake2.6docs.html#module:FindPkgConfig -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG's CMakeLists.txt
The PREFIX property does this:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES PREFIX ../)
For how it's used in the OSG's cmake macros, see OsgMacroUtils.cmake in
SETUP_EXE() and SETUP_PLUGIN()
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk/CMakeModules/OsgMacroUtils.cmake
On Thu, Apr 30, 2009 at 6:49 AM, Kim C Bale k.b...@hull.ac.uk wrote:
I’m trying to create a CMake project for an initial release of osgOcean
and I’d like to follow the OSG’s convention of piling all debug and release
libs and dlls into bin and lib folders appending D onto the end of the debug
libraries.
I’m quite new to CMake and I’m finding this quite frustrating, when you
create the visual studio project it appends debug or release to the file
path and nothing I can do will change its mind.
I notice that there’s a hack for it, as it’s mentioned in the OSG’s main
CMakeLists (see below).
..but I can’t spot the hack.. where is it?
Apologies for the off topic post but I’ve trawled the net for it and found
nothing, and I figured I’d get the quickest response about this here since
some of you clearly know your CMake onions.
Cheers.
Kim.
# the following options are MSVC specific,
# the first OSG_MSVC_VERSIONED_DLL activate a custom build-time layout that
should allow to run examples and application
# fron bin folder without requiring installation step.
# it also prepend osg${OPENSCENEGRAPH_SOVERSION}- to only .dll files,
leaving .lib files untouched in lib
# it also use a hack to get rid of Debug and Release folder in MSVC
projects
# all the .dll and .pdb are in bin and all the .lib and .exp are in lib
#
# the second option disable incremental linking in debug build , that is
enabled by default by CMake
##
*
To view the terms under which this email is distributed, please go to
http://www.hull.ac.uk/legal/email_disclaimer.html
*
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Initial cut at CMake support + branch of osgEphemeris
On Fri, Apr 10, 2009 at 11:33 AM, Robert Osfield
robert.osfi...@gmail.comwrote:
Which goes pretty sweetly till it tries to link the plugin. These are the
errors I get:
[ 86%] Building CXX object
src/osgEphemeris/CMakeFiles/osgEphemeris.dir/StarField.o
[ 93%] Building CXX object
src/osgEphemeris/CMakeFiles/osgEphemeris.dir/sun_image.o
Linking CXX shared library ../../lib/libosgEphemeris.so
[ 93%] Built target osgEphemeris
Scanning dependencies of target osgdb_osgephemeris
[100%] Building CXX object
src/osgPlugins/osgEphemeris/CMakeFiles/osgdb_osgephemeris.dir/IO_EphemerisModel.o
Linking CXX shared module /osgPlugins-2.9.2/osgdb_osgephemeris.so
/usr/bin/ld: cannot open output file
/osgPlugins-2.9.2/osgdb_osgephemeris.so: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [/osgPlugins-2.9.2/osgdb_osgephemeris.so] Error 1
make[1]: ***
[src/osgPlugins/osgEphemeris/CMakeFiles/osgdb_osgephemeris.dir/all] Error 2
Hmm, server appears down for me so I can't have a look at this right now.
I'm guessing that the problem has something to do with setting the PREFIX
target property which I think is what OSG uses to force the plugins into an
osgPlugins-x.y.z folder?
Could you add the following after the declaration of
add_library(osgephemeris MODULE...)
message(CMAKE_LIBRARY_PATH = ${CMAKE_LIBRARY_PATH})
message(CMAKE_LIBRARY_OUTPUT_DIRECTORY =
${CMAKE_LIBRARY_OUTPUT_DIRECTORY})
get_target_properties(the_prefix osgephemeris PREFIX)
message(the prefix is = ${the_prefix})
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Win64 configurations...
On Mon, Apr 13, 2009 at 6:09 PM, Andrew andr...@mac.com wrote: Hi, I have generated the 2.8.0 VS2005 Windows projects and .sln using CMake 2.6. Worked great and I have a set of buildable Win32 projects. Is there some way to get Win64 'configurations' in the generated projects without having to do it manually and painfully? I was expecting some switch in CMake perhaps? Am I just missing something obvious here? When you run cmake-gui or CMakeSetup when initially configuring your build directory there should be an option for Visual Studio 8 2005 Win64 and Visual Studio 9 2008 Win64. If you are not using an out-of-source build directory (which is generally a good idea) you will need to clear the CMake cache. There is a menu option for this or delete CMakeCache.txt. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Win64 configurations...
On Mon, Apr 13, 2009 at 10:11 PM, Andrew andr...@mac.com wrote: thanks, Now I remember So that means it is either/or? That, is you can have a Win32 set of projects or a Win64 set of projects. In an ideal world the 64-bit builds would just be a configuration. Yes, it's either/or. The big problem is that find_library() and other commands in CMake were designed to find one thing or do one thing. With something like a simultaneous 32/64-bit build you would need two libraries for every find_library() call, for example. Also you would have to decide what to do with compilation tests done during CMake configure time (do you compile them once or twice, for which compiler mode do you pick, etc.). There is also how to handle the case of one of your dependencies not having a 64-bit library available. Given the way CMake is written this would be impossible to do without running the script twice. find_library(FOO_LIBRARY foo) if(FOO_LIBRARY) add_executable(foo_example foo_example.cc) endif() Since you're going to run it twice anyways you might as well let the developer do it (is the CMake approach). I regularly create several build trees / configurations per source tree. MinGW, MSVC8, MSVC9, Linux GCC Debug, Linux GCC Release... You get used to it. :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Windows binary download
On Thu, Apr 2, 2009 at 3:57 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hello Martin, It's not a big deal - it's just one of those detail things that puts off new users if to try OSG they have to go and install some other third party app to open the download. If making them zip on windows is as easy as Mattias said, we should do it. Agreed. It's just that as Robert said, we had discussed it and no one had objected at the time. You're the first to bring it up since then (in about 2 months since the 2.8.0 release). But changing it is fine. I also think this is a good idea for end users. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Build problem with gdk-x11-2.0
On Wed, Apr 1, 2009 at 1:28 PM, Harry Plantinga hplan...@calvin.edu wrote: Hi, I'm trying to build OpenSceneGraph on a SUSE system. Attempts to make version 2.8 and 2.9.2 both yield the following error. Any suggestions? Thanks! -- [ 99%] Built target osgdb_svg Linking CXX shared module ../../../lib/osgPlugins-2.8.0/osgdb_pdf.so /usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld: cannot find -lgdk-x11-2.0 collect2: ld returned 1 exit status make[2]: *** [lib/osgPlugins-2.8.0/osgdb_pdf.so] Error 1 make[1]: *** [src/osgPlugins/pdf/CMakeFiles/osgdb_pdf.dir/all] Error 2 make: *** [all] Error 2 -- N.B. libgdk-x11-2.0.so.0 is there in the /opt/gnome/lib64 directory, where it's supposed to be according to CMakeCache.txt. Do you have the libgdk development packages installed for your distribution? There should be a libgdk-x11-2.0.so symbolic link (without .0) somewhere in /opt/gnome/lib64 along with header files. On Linux systems build systems like automake and CMake never search for versioned shared libraries directly but rather resolve the symbolic link libfoo.so=libfoo.so.1 to know that libfoo.so.1 is needed at runtime. Development packages that provide header files usually provide .so symbolic links or just plain .so files if versioning is not being used. OSG's cmake scripts should probably be telling you about this problem at configure time (this may be a build system bug). -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How do I add libraries to all linker commands?
On Tue, Mar 31, 2009 at 5:07 PM, Lucasw wsa...@gmail.com wrote: From your build tree type make edit_cache, this is the same as running ccmake /path/to/source/tree. Check the contents of the OPENGL_gl_LIBRARY and OPENGL_glu_LIBRARY variables. They should be pointed to the libraries you want to use for GL and GLU. They are under the Advanced section of the cache. Okay, after running make edit_cache 't' has to be pressed to get the advanced mode where the OPENGL variables are, and then I added /usr/lib/libGL.dll.a and /usr/lib/libGLU.dll.a to those variables (separated from the /usr/lib/w32api libs by semicolons). Then 'c' for configure and 'g' for generate, and then it exits and everything builds fine. Strange. On my Cygwin install with CMake 2.6.2 (on Cygwin) I get: OPENGL_INCLUDE_DIR /usr/include/w32api OPENGL_gl_LIBRARY /usr/lib/w32api/libopengl32.a OPENGL_glu_LIBRARY /usr/lib/w32api/libglu32.a What is the difference between /usr/lib/libGL.dll.a and /usr/lib/w32api/libopengl32.a? What version of CMake are you using? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] svn trunk(9972) linking problem.
2009/3/30 Robert Osfield robert.osfi...@gmail.com Hi Jose L. Cedric's sent me a fix for this last week, but I've been too busy to do a submissions purge so haven't got to it yet. I'll get to it tomorrow or Wednesday. That will solve my other broken build on the dashboard. I will move both to the Nightly section since they look like they'll be stable soon. :) http://www.cdash.org/CDashPublic/viewBuildError.php?buildid=16446 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows 7 beta: The binary is not a valid Windows image.
On Sat, Mar 28, 2009 at 11:24 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Thanks for your insight. You might be able to use the ProductName, CDSVersion, CurrentVersion, and/or CurrentBuildNumber fields in the following part of the registry to determine if you're building on the Windows 7 Beta. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion OK, seems ProductName contains Windows 7 Ultimate so using a test such as contains 'Windows 7' should work. 1. Use the output of reg query in an execute_process() cmake command (or something similar) reg query HKLM\Software\Microsoft\Windows NT\CurrentVersion /v CurrentBuildNumber Using execute_process(), will CMake return the resulting string? If so, can I then do a pattern match (like a regex) on that string? Yes, there is an option to execute_process() that will return the output as a string. See the CMake documentation. http://www.cmake.org/cmake/help/cmake2.6docs.html#command:execute_process You can use the STRING(REGEX REPLACE...) command in conjunction with ( ) to extract strings. See the FAQ below as well as the CMake manual for details. You should be able to find plenty of examples using Google. Beware escaping regular expressions in CMake is a bit weird. http://vtk.org/Wiki/CMake_FAQ#Which_regular_expressions_are_supported_by_CMake.3F -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] How do I add libraries to all linker commands?
On Sat, Mar 28, 2009 at 11:24 AM, Lucasw wsa...@gmail.com wrote: This is compiling OSG 2.8.0 and examples with the cmake generated files under cygwin, using standard gnu tools. I think there's a master file somewhere with LIBS or LDFLAGS or equivalent that gets passed to all the makefiles to which I need to add -lGL and -lGLU (otherwise there are lots of 'undefined reference to `_glAlphaFunc'' and similar errors). I did this manually for the main osg library, cutting and pasting the output of make VERBOSE=1 and adding those libs, but now there are dozens of examples and the manual method is too slow. From your build tree type make edit_cache, this is the same as running ccmake /path/to/source/tree. Check the contents of the OPENGL_gl_LIBRARY and OPENGL_glu_LIBRARY variables. They should be pointed to the libraries you want to use for GL and GLU. They are under the Advanced section of the cache. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows 7 beta: The binary is not a valid Windows image.
On Sat, Mar 28, 2009 at 11:44 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi all, If I get no opinions I'll just submit a modified CMakeLists.txt that includes /DYNAMICBASE. OK, perhaps it's a result of my previous message being overly verbose, but I got no responses. So I'm now going to do this and submit it. One question for CMake experts (Philip? Mattias?): is there some way to know the exact version of Windows? You might be able to use the ProductName, CDSVersion, CurrentVersion, and/or CurrentBuildNumber fields in the following part of the registry to determine if you're building on the Windows 7 Beta. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion Only problem is I have no idea how to easily get this information via CMake. It appears that CMake only supports reading from the registry as part of a find_path(), find_library(), etc. command. This kinda sucks and should be remedied. In the meantime, here are a few options: 1. Use the output of reg query in an execute_process() cmake command (or something similar) reg query HKLM\Software\Microsoft\Windows NT\CurrentVersion /v CurrentBuildNumber 2. Use CHECK_CXX_SOURCE_RUNS with your own calls to the Windows registry functions and have it return 0 or 1 depending on if Windows 7 beta is found 3. Do nothing and leave things the way you have them. When Windows 7 gold comes out hopefully the bug will be fixed by then. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/25 Robert Osfield robert.osfi...@gmail.com Hi Glenn, Philip et. al, 2009/3/25 Glenn Waldron gwald...@gmail.com PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser (http://code2009/3/24 Philip Lowman http://code.google.com/p/pacparserphi...@yhbt.com I really don't know anything about this particular topic, neither much about proxies or java script... but a few thoughts about the possible integration side. First up I'd suggest that if possible one should decouple the extra java script based proxy support from the plugin as we don't want a simple plugin with modest dependencies becoming burden with optional dependencies, as it'd mean that the plugin behaves differently in different builds. Might it be possible to decouple the Java script/PAC support completely. Perhaps via another plugin? Perhaps via Registry::ReadFileCallback? Or at the application level? Here are a couple of other options I thought of I'll throw out there 1. Build the curl plugin twice, once with curl and once with curl + pacparser (or whatever). Make it so the latter plugin is preferred in Registry.cpp if PAC usage is enabled, the plugin is available and it's loadable. This option might simplify some of the passing you'd otherwise have to do between the plugins if multiple plugins are used (I assume environment variables can't be used for this to set http_proxy/etc. due to multiple download threads). 2. use dlopen+dlsym in the existing curl plugin since pacparser is fairly lightweight and only has 4-5 functions. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Error on Windows
2009/3/24 Robert Osfield robert.osfi...@gmail.com Hi Philip, You do recall the fact the OSG versions it's dll/.so and plugins directory, and as you're hypothetical usage model totally ignores this fact it's pretty hard for me to take it too seriously. I had forgotten about that, yes good point. So what good does the compiled default search path do if libosgDB.so* is not in ld.so.conf or LD_LIBRARY_PATH? If libosgDB.so* is in one of these places everything automatically works. If not, nothing works at all. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Error on Windows
2009/3/24 Robert Osfield robert.osfi...@gmail.com Mark,On Tue, Mar 24, 2009 at 10:50 PM, Mark Sciabica msciab...@itracs.com wrote: Let me spell out specifically a sequence of events that will lead to a problem. http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Let me spell out... please read my previous email... If you feel that you want to disable this default behaviour then please add an option into the CMakeLists.txt file, and then submit this to me to merge. Can someone explain to me what the compilation behavior actually does? Assuming libosg.so or osg.dll is found, that means that the folder containing these is already in ld.so.conf or PATH or LD_LIBRARY_PATH, correct? The plugin search policy searches for plugins with files with a path appended, like osgPlugins-x.y.z/the_osg_plugin.dll. Wouldn't it automatically find the plugins folder due to the behavior of dlopen() and LoadLibrary() and not need a compiled hint? Clearly I'm missing a case here or something. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/24 Glenn Waldron gwald...@gmail.com I have a customer who is trying to use OSG to access data through a PAC proxy (http://en.wikipedia.org/wiki/Proxy_auto-config). CURL does not support this directly, and the sense I get from the CURL community is that they don't plan to. Does it make sense to add PAC proxy support to the OSG CURL plugin? Yes, you could deal with PAC at the application level and set the CURL proxy based on the results ... this is what the CURL folks advocate ... the trade-off though is that sample apps like osgviewer will not be able to work in a PAC proxy environment. Just looking to get some opinions on the matter. PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. Ultimately though it's far easier just to have a human being read the PAC file and say thou shalt export http_proxy=http://foo.internal.com:8080; prior to running the OSG. For servers that don't need the proxy server you can either configure the proxy server to tell the client to access the server directly or you can use the no_proxy environment variable which I believe libcurl respects. If you have a situation where you have to switch between two different proxy servers depending on the URL you are accessing clearly something is wrong with your IT people at work... :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proxy auto-config (PAC) support
2009/3/24 Glenn Waldron gwald...@gmail.com 2009/3/24 Philip Lowman phi...@yhbt.com 2009/3/24 Glenn Waldron gwald...@gmail.com I have a customer who is trying to use OSG to access data through a PAC proxy (http://en.wikipedia.org/wiki/Proxy_auto-config). CURL does not support this directly, and the sense I get from the CURL community is that they don't plan to. Does it make sense to add PAC proxy support to the OSG CURL plugin? Yes, you could deal with PAC at the application level and set the CURL proxy based on the results ... this is what the CURL folks advocate ... the trade-off though is that sample apps like osgviewer will not be able to work in a PAC proxy environment. Just looking to get some opinions on the matter. PAC requires javascript right? You could make it so the curl plugin optionally depends upon a javascript engine and if it's there it solves for the proper proxy to use. That would be the idea, yes. In particular I was looking at pacparser ( http://code.google.com/p/pacparser) which I believe uses spidermonkey for JS. It would be nice in that the OSG could at least in theory work with proxy servers without being configured at all. For servers that don't need the proxy server you can either configure the proxy server to tell the client to access the server directly or you can use the no_proxy environment variable which I believe libcurl respects. If you have a situation where you have to switch between two different proxy servers depending on the URL you are accessing clearly something is wrong with your IT people at work... :) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Build Error on Windows
On Mon, Mar 23, 2009 at 5:47 PM, Mark Sciabica msciab...@itracs.com wrote:
Hi Robert,
Sorry, I thought it would have been clear from my first e-mail. I'll try
again.
FileUtils.cpp in osgDB has this code.
static void appendInstallationLibraryFilePaths(osgDB::FilePathList
filepath)
{
#ifdef OSG_DEFAULT_LIBRARY_PATH
// Append the install prefix path to the library search path if
configured
filepath.push_back(ADDQUOTES(OSG_DEFAULT_LIBRARY_PATH));
#endif
}
osgDB's CMakeLists.txt has this line:
ADD_DEFINITIONS(-DOSG_DEFAULT_LIBRARY_PATH=${CMAKE_INSTALL_PREFIX}/lib${LIB_POSTFIX}/${OSG_PLUGINS})
This means that the install path configured at build time will be searched
for plugins. This does not make sense for prebuilt binaries because the
install location will likely be different on different machines. I propose
removing the function appendInstallationLibraryFilePaths, and also the line
in CMakeLists since it is only this function that makes use of it.
This is kinda dangerous too. What happens if:
1. User installs OSG 2.6 to /usr/local/OSG
2. User is happy
3. One day user decides to download OSG 2.8
4. User decides to move /usr/local/OSG = /usr/local/OSG-2.6
5. User compiles OSG 2.8 and installs to /usr/local/OSG again
6. User is happy but if they go to run their old OSG 2.6 build what
happens? My guess is that OSG 2.8 libraries are found.
What is ${LIB_POSTFIX} above. Is this supposed to be to facilitate debug
builds?
Is it possible to somehow find the location of osgDB.dll or libosgDB.so
within code as a way to solve the plugin loading problem. Then you could
simply append path_to_libosgDB.so + ../lib${LIB_POSTFIX}/${OSG_PLUGINS} to
the search path. I know you can do this with the binary that's being run
(if osgviewer is used for example). This wouldn't work for people running
an OSG app in a different path that uses libosgDB however.
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] unsubscribe
To unsubscribe visit the URL below: http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org On Sat, Mar 14, 2009 at 2:09 PM, Adrian Ferrier tdlfact...@yahoo.comwrote: unsubscribe ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.8.0-rc6 tagged, please test
On Tue, Feb 24, 2009 at 10:04 AM, Martin Spott martin.sp...@mgras.netwrote: Robert Osfield wrote: On Sun, Feb 22, 2009 at 9:54 PM, Martin Spott martin.sp...@mgras.net wrote: 1.) Point CMake to CURL- and probably other libraries like: -D CURL_LIBRARY=/opt/freeware/lib/libcurl.a \ -D CURL_INCLUDE_DIR=/opt/freeware/include/curl Did you build libcurl and other libraries yourself? Similarly to other Unix systems, there are well-known sources for AIX freeware packages which typically install into /opt/freeware/ (analogously to /usr/freeware/ on IRIX). If you could roll a list of these well-known freeware packages which install into /opt/freeware into a bug report on the CMake bug tracker I (or someone else) would probably be happy to look through the CMake Find modules and add the paths where they're needed. It's possible that libcurl may not be the only Find module with this problem. http://public.kitware.com/Bug -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Missing OpenThreads.lib after windows build (VS 2008)
OpenThreads.lib should be there. Are you sure the OpenThreads project built correctly in VisualStudio? What version of OSG is this? What version of CMake is this? On Sun, Mar 1, 2009 at 10:17 PM, Peter osgfo...@tevs.eu wrote: After running cmake and trying to build several examples all builds give this error. 1LINK : fatal error LNK1181: cannot open input file '..\..\lib\Release\..\OpenThreads.lib' Is this a missing undocumented dependency? If so where does this come from. Thanks, Peter -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7717#7717 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CMake 2.6a build system and OpenSceneGraph - problems with long paths?
On Thu, Feb 26, 2009 at 11:56 AM, Christian Buchner christian.buch...@gmail.com wrote: Hi, I've been trying to build OpenSceneGraph 2.8.0 from source, using Visual C++ 2008. I noticed a strange effect with the CMake 2.6a build system that results in some examples not getting built. I've placed OpenScenegraph in a subdirectory of the default Visual Studio 2008 projects folder and selected the a build subdirectory for generating the binaries (and project files) separately from source. D:\Documents and Settings\Christian Buchner\My Documents\Visual Studio 2008\Projects\SON\dependencies\openscenegraph-2.8.0\OpenSceneGraph Some examples with the longest filenames are not getting built. The EXE files are missing, yet the .obj files are being created. Visual C++ reports a Compiling... phase, but omits the Linking... phase. So I would expect th .EXE files to be generated in the following folder D:\Documents and Settings\Christian Buchner\My Documents\Visual Studio 2008\Projects\SON\dependencies\openscenegraph-2.8.0\OpenSceneGraph\build\bin But in my case the following examples have not been built (naturally leading to a failure to build the INSTALL project) osganimationskinning osganimationtimeline osgmultiplerendertargets osgmultitexturecontrol osgpackeddepthstencil osgwidgetperformance Now the questions are - who is to blame and how can we fix it? - myself for making too long paths? - CMake ? - Visual Studio 2008 (Standard) ? - Windows ? If anyone has run into similar problems and/or knows a remedy, please let me know. In the mean time I will such things as shortening the path, for example by renaming dependencies to deps and build to bld. I would definitely like to stay in the default location for Visual Studio projects - and I also want to keep my Windows user name ;-) I would try CMake 2.6.3 and see if the problem persists. If it doesn't go away you could try to reproduce using a small CMakeLists.txt file to confirm the character limit problem. It's entirely possible it could also be something with Visual Studio or your machine. There is this thread, but I don't think it's your problem. http://www.mail-archive.com/cm...@cmake.org/msg15377.html -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Packaging distribution under Windows
On Mon, Feb 23, 2009 at 6:51 PM, Sukender suky0...@free.fr wrote: Hi all Windows users (and others too, I'm not doing discrimination ;) ), Under Linux ( co), packages can have dependencies. Under Windows, we're far to have such an easy system. Question is: how could we redistribute efficiently the OSG binaries (I mean when not linking statically) alongside our apps? Here are my suggestions, please share your thoughts. 1. Manually copy the DLLs in the app's dir. That becomes a pain if you select each DLL by hand, and you may have multiple copies for each app. 2. Say to the user (s)he must download the OSG binaires. Not very user firendly, IMO. 3. Create a nice installer that contains the OSG packages. Thus the installer become obese since we don't need all the DLLs... 4. Create a nice installer that contains partial packages. Not very clean to begin splitting packages I think. 5. Create a nice installer that will download packages on the web. Nice, but what about installing on a machine that has no connection? Should we provide both online and offline installers? I'm starting a project called CMakePorts that aims to solve some of these goals. The goal would be to build many of the popular dependent libraries as part of the OSG and then since they would be make installed they could simply be picked up by CPack (and/or any installer someone might choose to contribute). http://code.google.com/p/cmakeports/wiki/CMakePortsPlan It's obviously still in the planning phase right now though. And about installers... Should we copy the DLLs to the system dir? What about Vista and its strange policies about having access to system dirs (I simply stayed under XP :D )? Assuming you want an application to be used by non-administrators and non-power users (certainly the case with the OSG, IMHO) you're always going to want the DLLs to at least be available alongside the .EXE files as an option in the installer. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake 2.6.3 brings easier OSG integration out-of-the-box
The release of CMake 2.6.3 includes a new find module which makes using the
OSG from within a project of your own much easier to do. There is also
version support available should you want to specify the minimum (or exact)
version of the OSG that is needed to build your project.
Here's a 6 line hello world example. Replace foo.cpp with the OSG app of
your choice and modify the find_package() line to contain the list of
nodekits/libraries you require.
CMakeLists.txt:
=
project(Foo)
cmake_minimum_required(VERSION 2.6.3)
find_package(OpenSceneGraph 2.8.0 REQUIRED osgUtil osgDB
osgWhateverNodekitsYouNeed)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cpp)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
==
If you need to set cmake_minimum_required to less than 2.6.3 please see the
documentation for FindOpenSceneGraph.cmake as you will need to copy a few
files from the 2.6.3 release of CMake into your CMake module path.
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with Windows debug binaries?
On Mon, Feb 16, 2009 at 11:48 AM, Norman Vine n...@cape.com wrote: Cory Riddell writes: A couple of notes: 1. I don't run as administrator all the time (it still amazes me how many Windows users always operate as an admin) 2. I untarred with cygwin's tar. Perhaps that does something funky with the permissions? My guess is you don't have the sp1 runtime http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14- 984d-389c36f85647displaylang=enhttp://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-%0A984d-389c36f85647displaylang=en Yeah, those ZIP releases of the OSG 2.8.0 prebuilts should really have the following files placed in the bin folder so they work out-of-the-box on Windows 2000, Windows XP, or Windows Vista without anyone having to install the MSVC runtime crap. *C:\Program Files\Microsoft Visual Studio 8\VC\Redist\x86\Microsoft.VC80.CRT *\* See: http://www.codeproject.com/KB/cpp/vcredists_x86.aspx The debug prebuilts can't have the debug runtime included with them for legal reasons. Also, adding the following should cause the Visual Studio 7, 7.1, 8 or 9 runtime libraries to be copied to the bin folder when someone runs the INSTALL target in Visual Studio. I can't test this at the moment since I don't own VS at home, only VS Express. This should make packaging up distributions of the OSG easier: INCLUDE(InstallRequiredSystemLibraries.cmake OPTIONAL) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with Windows debug binaries?
. Original Message ... On Tue, 17 Feb 2009 09:31:37 -0500 Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, Yeah, those ZIP releases of the OSG 2.8.0 prebuilts should really have the following files placed in the bin folder so they work out-of-the-box on Windows 2000, Windows XP, or Windows Vista without anyone having to install the MSVC runtime crap. IMHO, installing the MSVC runtime crap is preferable to copying the same DLLs in every release zip for every version of OSG (and potentially every other project we work on...) and therefore having potentially tens if not hundreds of copies of the same files on your system. Installing the redist ensures you have one copy (the right one) and it's accessible to all programs. Personally I would trade the whopping 1.6 MB this would take up for the assurance that the binaries will work on all machines. Of course if you want an end-user's first experience running osgviewer to view some model they found online to be a cryptic error message, then by all means leave things the way they are. Unfortunately, not every first time user of OSG is going to have MSVC installed or the runtime libraries installed. Yes I agree this sucks. Unfortunately the SxS runtime libraries do not come with Windows. There is no disadvantage to including the runtime DLLs aside from an extra 4 files and 1.6MB of space used. I think this is really a no brainer. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] problem with Windows debug binaries?
On Tue, Feb 17, 2009 at 2:25 PM, Sukender suky0...@free.fr wrote: Hi all, hi Robert, for Windows we could generate an .msi installer If CMake can do that, I'll open a bottle of Champagne! :) That would be great to directly generate an installer for each platform... CMake supports integration with NSIS. Not sure if there is support for MSI yet. Wix looks like a promising candidate. But to end up the discussion, I'll say, until we got a real installer (which is the best solution), that: - Tweaking the CMake script to add special DLLs in the tar.gz is a bad idea. DLLs should thus not be added in the archive. - There should be a note and a link on the dowload page (and maybe in a README as J-S suggested). I suggest Robert (or anyone having write access to this page) to add, after the Windows Visual Studio 8 packages the following wiki text: - Requires the MSVC 2005 SP1 redistributables for your platform ([ http://www.microsoft.com/downloads/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647x86], [ http://www.microsoft.com/downloads/details.aspx?FamilyID=eb4ebe2d-33c0-4a47-9dd4-b9a6d7bd44dax64] or [ http://www.microsoft.com/downloads/details.aspx?FamilyID=747aad7c-5d6b-4432-8186-85df93dd51a9IA64]; And the same for 2008 packages ( http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2(x86), http://www.microsoft.com/downloads/details.aspx?FamilyID=ba9257ca-337f-4b40-8c14-157cfdffee4e(x64), http://www.microsoft.com/downloads/details.aspx?FamilyID=dcc211e6-ab82-41d6-8dec-c79937393fe8(IA64)). Is that okay for everyone? No arguments here. Until an installer is once again available for casual end-users just linking the URLs you provided seems reasonable to me. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Resolving CDash errors/warning
On Mon, Feb 16, 2009 at 9:28 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Philip, I really haven't been monitoring the status of the OSG for quite a while now so I'm not extremely familiar with how you guys are kicking off your nightly builds. Our nightly builds are just additional projects in the VS solution / makefile. So we do either make Nightly or devenv path to OpenSceneGraph.sln /build Release /project Nightly I'll setup a couple of nightly's at work tomorrow and include the -A flag so people can have a look at what I'm doing. It really is as simple as tweaking the CMake examples I linked and stripping out some of the CMake specific stuff. Also change cvs to svn, obviously. The big advantage of running ctest -S foo.cmake is that you can test not only your build, but also your configure step. You can also share one source tree amongst all of your build configurations if you want and just kick off ctest -S multiple times in a nightly cronjob. Typically at work we use cron or Windows Scheduled Tasks to run the following command to build our source tree. ctest -S foo.cmake foo.cmake would contain something similar to the following: http://www.cdash.org/CDash/viewNotes.php?buildid=271884 http://www.cdash.org/CDash/viewNotes.php?buildid=271534 This allows us to tweak the initial cache to enable / disable various dependencies, etc. http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest Interesting, I'll have to take a look at this. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Resolving CDash errors/warning
On Sun, Feb 15, 2009 at 8:49 AM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi Philip,
In your CTest script set the following command:
I'm not sure, do we use CTest?
SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)
If we do use it, this could perhaps be made an option in the CMake config
for the project? I think since it's a nightly build, building the sources
from scratch each time is not too bad, and would let us see all
errors/warnings instead of just those on the files that changed since the
last compile.
Also, another useful tip is to add the -A flag to the command used to
run CTest. This will cause your CTest script to be visible on the public
dashboard.
SET (CTEST_COMMAND \/wherever/bin/ctest\ -D Nightly -A
\${CTEST_SCRIPT_DIRECTORY}/${CTEST_SCRIPT_NAME}\
)
I couldn't find any CTEST_COMMAND in our CMake scripts. As I said, I don't
know if we're using this at all... Perhaps it's our next step in the
adoption of all CMake has to offer :-)
I really haven't been monitoring the status of the OSG for quite a while now
so I'm not extremely familiar with how you guys are kicking off your nightly
builds.
Typically at work we use cron or Windows Scheduled Tasks to run the
following command to build our source tree.
ctest -S foo.cmake
foo.cmake would contain something similar to the following:
http://www.cdash.org/CDash/viewNotes.php?buildid=271884
http://www.cdash.org/CDash/viewNotes.php?buildid=271534
This allows us to tweak the initial cache to enable / disable various
dependencies, etc.
http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building popular dependencies from source (for WIN32 only) alongside OpenSceneGraph?
On Sat, Feb 14, 2009 at 9:42 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Philip, On Sat, Feb 14, 2009 at 8:07 AM, Philip Lowman phi...@yhbt.com wrote: One approach might be to discuss with the VTK guys about taking what they have done and turning it into it's own open-source project. Ideally this would allow both parties to contribute to the work and use whatever pieces they want in their own CM systems. This makes sense to me. I'm sure other projects need a similar set of dependencies that have a big overlap. It'd be like a mini little portable distro of dependencies. I have plenty of work on my plate, so I'd be happy if someone would step forward to approach the VTK team and help mentor the on going relationship (if one starts up). CC'ing me and interested contributors in on discussions. I'll mention it to them and see if they're interested. Luigi also is doing some work in this arena so I'll talk to him too. Also, if for whatever reason OSG decided not to build the 3rd party dependencies directly within the OSG, I don't think integrating the dependencies into the OSG distribution itself is approate, but having dependencies that are built in a similar way and can happily live alongside the OSG would be great. One might even be able to get the OSG's CMake system to integrate in some way with this dependencies distro. Yeah, poor wording above. I didn't mean to imply that the dependencies would be included with the OSG source distribution but rather that they could (as you suggested) be built by being called from the OSG's CMake instantiation. I've suggested it on the CMake mailing list and we'll see where things go from there. Hopefully we can get a lot of community participation which would certainly reduce the maintenance burden and get this idea rolling. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] building popular dependencies from source (for WIN32 only) alongside OpenSceneGraph?
On Fri, Feb 13, 2009 at 3:51 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Philip, I wonder if we could collaborate with the VTK guys on 3rd party dependencies, help create CMake support for each additional project we want to add in. One approach might be to discuss with the VTK guys about taking what they have done and turning it into it's own open-source project. Ideally this would allow both parties to contribute to the work and use whatever pieces they want in their own CM systems. Also, if for whatever reason OSG decided not to build the 3rd party dependencies directly within the OSG, you would at least have a way to point users to a project they could use to generate (most) dependencies for their own compiler of choice. I believe we could construct the CMakeified libraries to be able to be make installed as well as imported directly into existing projects. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Dashboard suggestion
On Mon, Feb 2, 2009 at 7:46 AM, Sukender suky0...@free.fr wrote: Hi all, I got an tiny idea... I suggest that people building OSG with dashboard reports (Nightly, Continuous, Experimental), use a site name that includes their name on osg-users list (such as blah blah blah - my OSG name), so that it would be easier for Robert (and maybe others) to identify the builders. So, is it possible to set the default value of the CMake variable to something like Machine name - OSG_USER_NAME environment variable, so that we don't have to put it manually each time we clear the CMake cache? Or else, you could simply fill a shared speadsheet with our name and our sites names... (I think I'll do it if the first idea is not trivial to do). There is another option. People who submit reports to the dashboard should create accounts on the OSG dashboard, set themselves as site maintainers and claim ownership over their sites (typically hostnames). This can allow CDash to send them emails if their build has a large number of errors or if their site doesn't submit an expected nightly build. If there isn't already a feature that allows an admin to see who owns which sites one could be added. Worst case someone with server access could execute an SQL statement to look this up. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Resolving CDash errors/warning
On Tue, Feb 3, 2009 at 3:46 PM, Jean-Sébastien Guay
jean-sebastien.g...@cm-labs.com wrote:
Hi Robert,
I just added a nightly build scheduled task on my machine, and ran it a few
times to see how it ran. You can see WHITESTAR is me. (incidentally, I
changed my site name to WHITESTAR_jean-sebastien_guay at one time, but
didn't change it the next time - anyone know how to remove an unused entry
in the CDash page? :-) )
It seems to me that using /build will not really be useful to track
warnings, since only changed .cpp files and files that depend on changed
headers will be recompiled each time, so getting 0 warnings doesn't mean
there are 0 warnings in the whole build, just in the subset of files
compiled.
I tried using /rebuild, but that seems to only rebuild the CMake
configuration, not the individual projects (the
WHITESTAR_jean-sebastien_guay build was done with /rebuild, and you can see
that only one file was compiled if you look at the build log). So using
devenv OpenSceneGraph.sln /rebuild Release /project Nightly
doesn't seem to work as expected. I used /build and instead deleted my
build directory's contents in order to rebuild everything. Perhaps I'm doing
something wrong.
In your CTest script set the following command:
SET(CTEST_START_WITH_EMPTY_BINARY_DIRECTORY TRUE)
Also, another useful tip is to add the -A flag to the command used to run
CTest. This will cause your CTest script to be visible on the public
dashboard.
SET (CTEST_COMMAND
\/wherever/bin/ctest\ -D Nightly -A
\${CTEST_SCRIPT_DIRECTORY}/${CTEST_SCRIPT_NAME}\
)
The CMake dashboard is also a treasure-trove of information regarding how to
setup a CTest script:
http://www.cdash.org/CDash/index.php?project=CMake
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with OpenSceneGraph and Codeblocks
On Wed, Feb 11, 2009 at 3:27 PM, Trust.Tee trust@gmx.net wrote: Hello, does anyone use OpenSceneGraph with Codebocks and can tell me, what i have to set up in CMake and Codeblocks to get it run. I've tried to find an example, but unfortunately i've found nothing. I would take this up on the CMake mailing list if you get stumped. I've never used Codeblocks or the CMake Codeblocks generator before but CMake appears to have support for it. To get a list of CMake generators you can pass --help as a flag, and then -G Generator Name. Hopefully it shouldn't be hard to import the generated project into Codeblocks after that??? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] building popular dependencies from source (for WIN32 only) alongside OpenSceneGraph?
A recent thread[1] on the CMake mailing list got me thinking about OSG and the 3rd party dependency issue on Windows. To solve this problem in VTK, the Kitware team basically compiles libjpeg, libtiff, libpng, libfreetype and more right alongside their source code. They've already CMakeified all of this and the code is publicly available on their CVS[2] repository (see kwpng, kwjpeg, etc.) It would be very cool to start a folder within OSG's svn for building these different source packages (but outside the OpenSceneGraph project) that could be checked out alongside OpenSceneGraph. CMake could then be configured to build and link against those libraries while on a Windows platform where the libraries aren't available. Obviously this isn't something you would necessarily do for all dependencies but at least for the lightweight ones which are absolutely necessary to having a somewhat functional OSG (jpeg, png, and freetype come to mind). With most developers having multiple cores, I'm pretty sure you could build libraries like libtiff and libjpg relatively quickly. A slower initial build time and need to redistribute a ZIP file alongside the OSG for WIN32 users would be the only cons I can think of. Benefits would be * No need to maintain MSVC 7.1, 8.0, 9.0, MinGW or Cygwin builds of the libraries since they would build themselves * Static builds become easier Furthermore, for libraries that don't make sense to build as part of the OSG like the SDL, additional folders could be created to contain prebuilts much as is done right now. Linux and MacOSX users wouldn't be affected by any of this because they likely would never checkout this folder. [1] = http://www.cmake.org/pipermail/cmake/2009-February/026964.html [2] = http://www.cmake.org/pipermail/cmake/2009-February/027019.html -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test svn/trunk in prep for 2.7.9 dev release
On Mon, Feb 2, 2009 at 10:36 AM, Paul Melis p...@science.uva.nl wrote: Robert Osfield wrote: Hi Sukender, I apply a pain vs gain to this type of decision. How much pain is it to maintain 2.4.x support vs how much pain it would be to those who'd have to upgrade, and also against how much we have to gain in streamlining our own maintenance work. Right now for Cmake 2.4.x it doesn't seem too difficult to retain support. One reason I like CMake 2.6 more than 2.4 is that it seems to have worked around the stupid and time-consuming relink step that it did when doing make install. When I call make and it finishes I expect to have a fully built set of libraries and executables, not something that isn't directly installable by simply copying files to a destination directory. I'm on a system where only CMake 2.4 is available, btw, but it's hardly any pain to compile and install 2.6 by hand. Unless I'm patching CVS I've actually gotten used to just using the prebuilt binaries on CMake.org's website for i386 Linux. They seem to work fine pretty much anywhere I've tried them. http://www.cmake.org/cmake/resources/software.html http://www.cmake.org/files/v2.6/ -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori l.cal...@cineca.it wrote: Hi Philip: I did not know you has access to the CMake CVS, good to know,. I had to change my FindOSG as I need to find also .dll and .so on windows and linux. So I needed both version as well soversion, so I decided to run the osgversion utility Furthermore, it seem to me that osgversion provide other flags to check for defines that have been specified in the build process of the osg found. like OSG_USE_FLOAT_MATRIX, OSG_USE_FLOAT_PLANE or OSG_USE_FLOAT_BOUNDINGSPHERE, are those still required to be defined when compiling against osg or they are not used anymore? That is a good question, I'm not sure when osg/Config was added to the build in relation to those preprocessor definitions being added. I decided to grab VPB version of FindOSG as really do not fully understand the nedd of a separate Findosgcomponent . I see that other Find modules that have multiple components such as ImageMagick are implemented as single file. In my opinion, having a single file is more handy if you do not use cvs CMake and also help in keeping the distributed CMake Modules directory cleaned, I think we could just find all the components available in the standard place and test the requirements against them. We can't remove FindosgComponent.cmake from CMake for backwards compatibility reasons so I've instead focused on making those files as tiny as possible and clumping the function calls in Findosg_functions.cmake. I think eventually the extensibility of FindOpenSceneGraph.cmake will pay off. In the long term it can be used by 3rd party nodekit developers so they can write their own FindosgFoo.cmake to allow their nodekits to be found alongside the OSG, without having to worry about submitting code patches to allow their nodekit to be detected. Obviously in the short term so long as you can't declare CMake minimum version = 2.6.3 the only real annoyance (assuming you want to use this at all) is needing to download CM 4+x files in your CMAKE_MODULE_PATH (where x = the number of nodekits you use in your project). Of these 4+x files only 2 will likely ever change, Findosg_functions.cmake FindOpenSceneGraph.cmake. Findosg.cmake FindOpenThreads.cmake are obviously always required for very good reasons. =) If some of the macro I use for copying lib and plugins dll could be useful to someone else, let me know, I can try to assemble them better. There is something new in CMake called GetPrerequisites.cmake you may want to investigate. I assume it may still may have some bugs in it, but it aims at determining the DLL dependencies of your LIB files at which point you can do whatever you want with the list (copy to build tree, INSTALL(), etc.) Making it easier for new CMake users to copy files to either MSVC build trees or standard build trees is something I'd like to see supported within CMake/Modules with an easy to use API. Everybody seems to have either come up with their own home-brewed solution for this one or have cobbled together something from mailing list posts. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 5:07 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Philip, It's good to see Cmake support for OpenSceneGraph being improved. I see it's moved on quite a bit from my own little experiments with FindOSG.cmake for VirtualPlanetBuilder + Present3D. I've just reviewed the new OSG related Cmake files in CMake CVS and it's enough different that I can't assess whether or not something that I addressed recently in the P3D FindOSG.cmake (back ported to OpenSceneGraph/CMakeModules/FindOSG.cmake) is also addressed. So perhaps you can clarify this for me. The problem that I addressed was thatthat CMake was search system directories for the OSG headers and libs prior to searching the OSGDIR env vars, this meant that if an older OSG version was already installed but a a different version was compiled locally and pointed at by the OSGDIR the installed version would always be found. To fix this I had to split the FIND* calls in such as a way that the OSGDIR path was checked in one FIND* call, then the system directories were called afterwards in their of FIND* call. In the CMake CVS version of FindOpenSceneGraph is it still possible to override the system paths or explicitly use a local version of the OSG? Yes. The problem you were having was a limitation in CMake 2.4.x that many people got around by calling FIND_LIBRARY() twice, once with NO_DEFAULT_PATH and the variable in PATHS, and then the normal call. This proved very cumbersome so the HINTS option was added in 2.6.0 which is just like PATHS but it happens BEFORE searching the system paths. The support for CMAKE_PREFIX_PATH, which was also added in 2.6.0 (both as an environment variable and as a CMake variable) supersedes HINTS. It turns out if you set CMAKE_PREFIX_PATH properly you can usually find pretty much any package in a special place without having to rely on a special environment variable or CMake variable for each one. Obviously I still like having per-package environment variables though and CMake CVS supports a wide range of possibilities, (OSG_DIR, OSGDIR, OSG_ROOT, etc.). There is even a per nodekit environment variable you can use that must have been thrown in for good measure which is obviously still supported (OSGKIT_DIR). :) The 2.6.x documentation does a good job of explaining the search process that find_library(), find_path(), and find_program() go through, if you're curious. http://www.cmake.org/cmake/help/cmake2.6docs.html#command:find_library -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori l.cal...@cineca.it wrote: Philip Lowman ha scritto: On Sat, Jan 31, 2009 at 4:22 AM, Luigi Calori l.cal...@cineca.itmailto: l.cal...@cineca.it wrote: Hi Philip: I did not know you has access to the CMake CVS, good to know,. I had to change my FindOSG as I need to find also .dll and .so on windows and linux. So I needed both version as well soversion, so I decided to run the osgversion utility Furthermore, it seem to me that osgversion provide other flags to check for defines that have been specified in the build process of the osg found. like OSG_USE_FLOAT_MATRIX, OSG_USE_FLOAT_PLANE or OSG_USE_FLOAT_BOUNDINGSPHERE, are those still required to be defined when compiling against osg or they are not used anymore? That is a good question, I'm not sure when osg/Config was added to the build in relation to those preprocessor definitions being added. Robert should clarify it, and also if is more robust to look at headers or to run osgversion to get version number Header file parsing has an advantage in that it doesn't rely on the user having their LD_LIBRARY_PATH or ld.so.conf file configured properly to run osgversion. Provided Robert doesn't add non-numerics to his version numbering scheme I'm fairly certain the regex shouldn't break. By all means, please have a look. Better to fix any possible issues now than later. http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/FindOpenSceneGraph.cmake?root=CMakeview=markup We can't remove FindosgComponent.cmake from CMake for backwards compatibility reasons so I've instead focused on making those files as tiny as possible and clumping the function calls in Findosg_functions.cmake. Well, that's also a CMake policy: if any findable package define one Findxxx file for his sub-package the Modules folder will probably grow a lot. I do agree with you that the FindosgComponent.cmake arrangement is probably not the best idea for most projects. For the OSG with its many external nodekits I don't think it was a bad choice at all. Regarding the argument that there may be too many files in the Modules folder, I've heard it. My response is that the more files in Modules, the better. I'd like to see 1000 files in Modules. Provided the package is somewhat popular, it should have a find module. I think eventually the extensibility of FindOpenSceneGraph.cmake will pay off. In the long term it can be used by 3rd party nodekit developers so they can write their own FindosgFoo.cmake to allow their nodekits to be found alongside the OSG, without having to worry about submitting code patches to allow their nodekit to be detected. Obviously in the short term so long as you can't declare CMake minimum version = 2.6.3 the only real annoyance (assuming you want to use this at all) is needing to download CM 4+x files in your CMAKE_MODULE_PATH (where x = the number of nodekits you use in your project). Of these 4+x files only 2 will likely ever change, Findosg_functions.cmake FindOpenSceneGraph.cmake. Findosg.cmake FindOpenThreads.cmake are obviously always required for very good reasons. =) OpenThreads is a different package, so, even if it is most used in OSG, it deserves his own separate Find, instead, the difference between FindOpenSceneGraph and Findosg is not clear to me. Findosg just finds libosg.so and osg.lib. Similarly FindosgDB just finds libosgDB.so and osgDB.lib. FindOpenSceneGraph orchestrates calling all of these small find modules. And yes, I've put a warning note in Findosg.cmake to steer the new user to FindOpenSceneGraph.cmake. We can't dramatically change the behavior of Findosg.cmake, again, for backwards compatibility reasons. CMake aspires towards 0 user build regressions on version upgrades both in Source/ and in Modules/ There is something new in CMake called GetPrerequisites.cmake you may want to investigate. I assume it may still may have some bugs in it, but it aims at determining the DLL dependencies of your LIB files at which point you can do whatever you want with the list (copy to build tree, INSTALL(), etc.) I had looked at it but not used as It seems in CVS only and not seen clear example usage, It seems to me it try to infer dll requiremets by parsing output from dumpin under windows or ldd under linux it is an interesting approach, not know if it is already usable. Have you an idea if it'll go into cmake 2.6.3 or just 2.7? That would be up to module author and Bill. I have no idea if it's been requested for backporting or how stable the code is. I actually haven't had time to use it myself, I only learned of it's existence a few days ago. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Sat, Jan 31, 2009 at 7:59 PM, Luigi Calori l.cal...@cineca.it wrote: Philip Lowman ha scritto: On Sat, Jan 31, 2009 at 9:47 AM, Luigi Calori l.cal...@cineca.itmailto: l.cal...@cineca.it wrote: Findosg just finds libosg.so and osg.lib. Similarly FindosgDB just finds libosgDB.so and osgDB.lib. FindOpenSceneGraph orchestrates calling all of these small find modules. And yes, I've put a warning note in Findosg.cmake to steer the new user to FindOpenSceneGraph.cmake. We can't dramatically change the behavior of Findosg.cmake, again, for backwards compatibility reasons. CMake aspires towards 0 user build regressions on version upgrades both in Source/ and in Modules/ I do not know how much are the single Findosgcomponent used compared to FindOpenSceneGraph, if there are many, than compatibility issues are important, otherwise probably not.. It's impossible to tell. I know of at least three projects that use them. If you'd like to make FindOpenSceneGraph work so that it only needs to depend on Findosg_functions.cmake I would be fine with that provided that if it encounters a node-kit it doesn't know about that it falls back on calling find_package(FindosgKit.cmake). This might be a happier solution for everyone. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Installing library plugins to the osgPlugins-VERSION directory
On Thu, Jan 29, 2009 at 10:39 AM, Luigi Calori l.cal...@cineca.it wrote:
This is my FindOSG file I use for getting dll to copy , it get the version
also... see
#get version numbers
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --version-number OUTPUT_VARIABLE
OSG_VERSION_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --so-number OUTPUT_VARIABLE
OSG_SO_NUMBER)
EXEC_PROGRAM(${OSG_VERSION_APP} ARGS --openthreads-soversion-number
OUTPUT_VARIABLE OSG_OT_SO_NUMBER)
I agree the FindOSG should be distributed along OSG.
My version need to find .dll under windows to copy them into a packaged
distribution (Firefox plugin)
I use it under Windows and Linux not tested on Mac
A lot of work has been done recently in CVS CMake to improve the Find
modules shipped with CMake (originally written by Eric Wing) to better work
with the OSG. I believe most of the features Luigi has added to his
FindOSG.cmake should be present there with a couple of improvements:
1. Component support
2. It should be trivial to add find modules for new nodekits (bundled with
OSG or not) without modifying the core FindOpenSceneGraph.cmake file
3. Version support and enforcement (by header file parsing)
4. Backwards compatibility with older versions of OSG that lack newer node
kits. It will not search for nodekits until told to do so.
I left out exposing the SO version figuring that users that need this level
of detail can just include osg/Version (or osg/Config in the case of
double/float issues) and write their own configure tests. Also SO
versioning isn't available on all versions of the OSG anyways.
Here's a brief synopsis of how to use it. As you can see, it is very easy
for the end user. It should work anywhere from 2.0.0 to 2.7.9 and might
even work with 1.2.0 although I don't have binaries around to test this. =)
Please see the documentation for more details.
find_package(OpenSceneGraph 2.0.0 REQUIRED osgDB osgGA osgViewer osgUtil)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cc)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
If you feel anything is missing or if you try it and it doesn't work please
file a bug in the CMake bug tracker. I and others in the CMake community
will support these modules with your patches (especially now that I have
commit access =) ). All of the above should be included in the upcoming
CMake 2.6.3 release. If you prefer not to muck with CVS I will post when an
RC that includes the modules is available.
One minor downside to it is that if you can't set
cmake_minimum_required(VERSION 2.6.3) for your project, you'll have to
include more than one file in your CMAKE_MODULE_PATH. This is also a bit of
a good thing, however, as developers should be able to simply distribute a 5
line FindosgFoo.cmake for their new nodekits and there will be no need to
continuously patch a FindOpenSceneGraph.cmake over the long term as it will
be distributed with CMake. Also if your project doesn't need the osgFoo
nodekit you would never need to download the FindosgFoo.cmake file.
http://public.kitware.com/cgi-bin/viewcvs.cgi/Modules/?root=CMake
See:
FindOpenSceneGraph.cmake
Findosg_functions.cmake
Findosg.cmake (depends on Findosg_functions.cmake)
FindosgDB.cmake (depends on Findosg_functions.cmake)
Findosg*.cmake (depends on Findosg_functions.cmake)
FindOpenThreads.cmake
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] A couple of Cmake issues with 2.6
On Thu, Sep 18, 2008 at 11:48 AM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: found the issue with the cl : Command line warning D9025 : overriding '/Fotg_OpenThreads.dir\Debug\' with '/Fo' cl : Command line error D8016 : '/fp:fast' and '/fp:except' command-line options are incompatible Some command line option were gettng added incorrectly so rjust removing them all solved that Still not sure why I get osg.lib and osgD.lib in my debug linker inputs Could you elaborate a bit more? Are you getting osg.lib and osgD.lib inputs in your own CMake project or is this within the OSG? What version of OSG / CMake are you using? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem installing OpenSceneGraph 2.6.0
On Tue, Aug 19, 2008 at 2:17 PM, Denis Nikolskiy [EMAIL PROTECTED] wrote: Hi All, I'm having trouble installing osg 2.6 on a Linux box. I don't have administrative privilege on that machine so I have to install osg into my directory. Using ccmake I specify the directory where I want to install osg and generate make files. Make command executes without any problems. Make install works without any problems until it hits osgviewer. Here is the error massage: CMake Error at applications/osgviewer/cmake_install.cmake:41 (FILE): file INSTALL cannot find file /scratch/nikolski/osg/osg2.6/bin/osgviewer to install. Call Stack (most recent call first): applications/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:38 (INCLUDE) I looked into specified directory (/scratch/nikolski/osg/osg2.6/bin/). All other binaries are there except osgviewer. I remade the whole thing again and made sure that osgviewer was in the bin directory. Make install after running for a while produced the same error message. I looked into the bin directory and osgviewer wasn't there anymore. I use cmake version 2.6. (I have Fedora Core 7, x86_64 in case it helps). I had no problems installing osg 2.5 on the same Machine. Did anyone have a similar problem, or does anyone have any ideas about what can cause it? I'm not sure exactly what you're doing, but to change the make install path all you should have to do is set the CMAKE_INSTALL_PREFIX variable. This is the equivalent of automake's ./configure --prefix=/foo. It default to /usr/local which may explain your permission problem when running make install -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GL_MAX_SAMPLES_EXT was not declared compile bug in OSG 2.6 release branch
I got this compile error building on a Centos 5 box this afternoon. Looks like glext.h isn't being #included /home/lowmanp/svn/OpenSceneGraph-2.6/src/osg/FrameBufferObject.cpp: In static member function 'static int osg::RenderBuffer::getMaxSamples(unsigned int, const osg::FBOExtensions*)': /home/lowmanp/svn/OpenSceneGraph-2.6/src/osg/FrameBufferObject.cpp:221: error: 'GL_MAX_SAMPLES_EXT' was not declared in this scope make[2]: *** [src/osg/CMakeFiles/osg.dir/FrameBufferObject.o] Error 1 make[2]: *** Waiting for unfinished jobs make[1]: *** [src/osg/CMakeFiles/osg.dir/all] Error 2 make: *** [all] Error 2 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg make error in mingw
2008/7/30 songbo_1220 [EMAIL PROTECTED] hi Philip Lowman! You really a good man！ I have read this page, on the mingw osg compiled, http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Mingw but feel it's too low osg version, so i didn't do that, first, i creat msys-osg using cmake, then, I made osg directness using msys-make, whether or not to do some things before makeing? thank you for your help! Yes, that page is out of date. I will update it if I can figure out how to edit the darn wiki. Anyways, to compile the OSG using MinGW (with no external dependencies) here is what I do. These directions are for MinGW makefiles though and not MSYS I think. 1. Run CMake, point to source and build directory 2. Configure for MinGW Makefiles 3. Set CMAKE_BUILD_TYPE as desired 4. If and ONLY if you have OSG 2.0,2.2, or 2.4 binary packages installed you must modify JPEG_LIBRARY, TIFF_LIBRARY, etc. to blank them 4a. If you are using CMake 2.6.0, there is a bug preventing you from blanking JPEG_LIBRARY (fix in 2.6.1 or search CMake bugtracker for 2 line patch) 5. Generate 6. Run command prompt, cd to build directory 7. C:\MinGW\bin\mingw32-make If you need external dependencies presumably you'd have to obtain or compile all of the various libraries yourself. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg make error in mingw
2008/7/30 songbo_1220 [EMAIL PROTECTED] hi Philip Lowman! my mingw version is binutils 2.18.50 gcc 4.3.0 runtime 3.14 w32api 3.11 gdb 6.8 my msys version is core 1.0.11 thanks!!! Songbo, The GCC 4.3.0 release for MinGW is listed as alpha quality software (which could explain the internal compiler error you got). I would suggest using the current stable release of MinGW which includes GCC 3.4.5 and see if that works better. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MSVC9 CMake bug in src/CMakeLists.txt ?
I was looking for something else and came across this in src/CMakeLists.txt and it looked a little odd. I thought I would ask the question if this was meant to apply to VS9 as well? If so, MSVC_VERSION should probably be used here. IF(MSVC80) OPTION(OSG_MSVC_GENERATE_PLUGINS_AND_WRAPPERS_MANIFESTS Generate or not manifests files under VS8 for dynamically loaded dlls ON) ENDIF(MSVC80) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG2.4 and 2.5.5 Windows static build problems
On Mon, Jul 21, 2008 at 5:21 AM, Stephan Maximilian Huber [EMAIL PROTECTED] wrote: Christiansen, Brad schrieb: Hi, I have searched the archive but cant find any mention of the problem, though I think can remember reading about a solution some time ago on the list. I have just tried to build the static version of OSG v2.4 and v2.5.5 using ViualStudio .Net 2003. When I do this build I get 5000+ warnings about dulpicate definitions when linking (LNK 4006). I then cannot link my aplication against the resulting .libs. Has anyone else encountered this problem and have a fix / workaround? Are these link-errors related to OpenThreads? A quick and dirty fiy would be: change CMakeLists for all osg-libs/src from IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) to IF (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY) ELSE (DYNAMIC_OPENSCENEGRAPH) ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC) ADD_DEFINITIONS(-DOT_LIBRARY_STATIC) ENDIF(DYNAMIC_OPENSCENEGRAPH) The underlying problem is: The setting, that you compiled OpenThreads statically is not carried out to a public header or something. If another lib includes a header-file of OpenThreads the compiler thinks, that OpenThreads is linked for dynamic-usage (because OT_LIBARY_STATIC is not defined so the EXPORT-definition for OpenThreads is not setup correctly), so you'll get multiple defined symbols, when you try to link your app with static OpenThreads and static osg, because osg includes OpenThreads-symbols for dynamic-linking. IMHO the definition of OT_LIBARY_STATIC should be carried out to OpenThreads/Config. The same should be done for OSG_LIBRARY_STATIC. On Linux there's no such problem, because you don't have to declare different exports for static versus dynamic linking. I am no expert in CMake, so perhaps somebody may jump in here? You can add OT_LIBRARY_STATIC to OpenThreads/Config but it does rule out the ability to #include the same set of headers and alternate between a static and a shared library version of OpenThreads on MSVC. It's not uncommon to ship a foo.lib and a foo_static.lib or foo_a.lib with a particular library so the user can choose between either. It would be relatively easy to add this to OpenThreads one day if it was desired (also generation of libOpenThreads.a) but it would be impossible to arbitrate between the two on MSVC (without using separate install prefixes) if the selection was done in the OpenThreads/Config header file. I'd say the right thing to do in this case is to push this issue to the user actually linking against the code, in other words the OSG, with the initial fix you suggested. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MSVC9 CMake bug in src/CMakeLists.txt ?
On Mon, Jul 21, 2008 at 7:45 AM, Serge Lages [EMAIL PROTECTED] wrote: Hi Philip, I added this option some time ago, and VS9 wasn't still available. So feel free to update it and add VS9. As a side note, is it possible to make a condition like all VS versions superiors to 8 ? On Mon, Jul 21, 2008 at 1:31 PM, Philip Lowman [EMAIL PROTECTED] wrote: I was looking for something else and came across this in src/CMakeLists.txt and it looked a little odd. I thought I would ask the question if this was meant to apply to VS9 as well? If so, MSVC_VERSION should probably be used here. IF(MSVC80) OPTION(OSG_MSVC_GENERATE_PLUGINS_AND_WRAPPERS_MANIFESTS Generate or not manifests files under VS8 for dynamically loaded dlls ON) ENDIF(MSVC80) I think this might work although I can't test (either if this conditional will work or if manifest generation on MSVC9 will work properly) IF(MSVC_VERSION EQUAL 1400 OR MSVC_VERSION GREATER 1400) # do stuff http://predef.sourceforge.net/precomp.html#sec32 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] integrating an external project to OSG via CMake
On Fri, Jul 18, 2008 at 5:35 PM, Mike Weiblen [EMAIL PROTECTED]
wrote:
Intending to finally get osgToy and osgVRPN building again with modern
OSG via CMake.
I've looked at several other independent nodekits/apps for guidance
(osggis, mpv, osgppu, vpb, etc) and they all have separate
CMakeModules directories and use slightly different versions of
FindOSG.cmake, apparently derived from a single ancestor version in
OSG itself (which is the oldest)
Is there a single definitive package of CMake goodies (including
FindOSG.cmake) for uniformly but compatibly building independent (or
interdependent) nodekits against OSG? I'm hoping there are some
resources to jumpstart that integration, else I may need to punt and
just create hardcoded VS projects for shortterm results.
Mike,
I've submitted a patch to improve the OSG modules released as part of CMake
2.6.x. It's sitting[1] in the CMake bugtracker, presently unassigned. You
could download[2] the latest RC for the upcoming CMake 2.6.1 (or just wait
for it to be released, which should be any day now) and use the modules from
the patch and they should work fairly well for you in terms of detecting the
OSG nodekits and linking against them. The modules won't work with CMake
2.6.0 due to the use of a new feature of find_library called HINTS.
[1] http://public.kitware.com/Bug/view.php?id=7331
[2] http://www.cmake.org/files/v2.6/
The patch facilitates external use of the OSG from MSVC/Win32 which is
something the official OSG CMake modules don't support directly because they
don't have detection of DEBUG libraries of the OSG.
The modules work a little differently from the all-inclusive
FindOpenSceneGraph.cmake that's been floating around in that you must call
FIND_PACKAGE() for both the OSG and any nodekits you're planning on using.
Depending on how many nodekits your project needs this might be a few extra
calls to FIND_PACKAGE() but for projects that don't need every library
released with the OSG being able to include them separately keeps the CMake
cache less cluttered.
find_package(osg) yields...
OSG_INCLUDE_DIR
OSG_LIBRARY
OSG_LIBRARY_DEBUG
find_package(osgDB) yields...
OSGDB_INCLUDE_DIR
OSGDB_LIBRARY
OSGDB_LIBRARY_DEBUG
etc.
On platforms other than MSVC the _LIBRARY_DEBUG variable is simply set to
the contents of the _LIBRARY which allows for a relatively simple
target_link_libraries(foo optimized ${OSG_LIBRARY} debug
${OSG_LIBRARY_DEBUG}) that will work for all platforms.
I have updated the patch to support osgWidget as well. If anyone has any
additional suggestions to improve the modules, I'm all ears.
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INSTALL include pdb's
Is there a linking flag you can use to change the generated .pdb filename in Visual Studio? If so, you could simply use CMake to tweak the targets that have conflicting names (see set_target_properties() command) .. Original Message ... On Thu, 10 Jul 2008 22:45:13 -0500 James Killian [EMAIL PROTECTED] wrote: Thanks for response... I'll look into that... but first there is a bigger problem with osgviewer. I'll have to double check, but by default the Applications osgviewer and osgViewer (dll) writing the same pdb file to the same place, and guess which one get overwritten (No windows does not allow case sensitive duplicate files)... Yep the DLL one, the one I need to see in my call stack crash. G I think the Application osgviewer project name should be renamed, or these .exe files build their pdbs to a different folder (preferably renamed). Can someone verify this is a legitimate problem... thanks. Jean? James Killian - Original Message - From: Philip Lowman To: OpenSceneGraph Users Sent: Thursday, July 10, 2008 9:52 PM Subject: Re: [osg-users] INSTALL include pdb's On Thu, Jul 10, 2008 at 10:40 PM, James Killian [EMAIL PROTECTED] wrote: Hmmm no one has responded... I can figure out where in cmake to make the change, if I add it would anyone have any objections? (If no one responds... I'll assume its fine to add) I believe you'll want to have a look at the INSTALL(FILES...) and/or ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD COMMAND) commands as possibilities. If you end up needing ADD_CUSTOM_COMMAND consider using cmake -E copy_if_different instead of copy. I'm out of town and don't have access to a VS development environment otherwise I think I could come up with something for you. This may also not be a bad feature to add to CMake itself if simply deploying the PDB files alongside the debug DLL file buys you this functionality. -- Philip Lowman --- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraphorg/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 -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Old Windows Binaries Problem.
On Thu, Jul 10, 2008 at 4:11 AM, Ümit Uzun [EMAIL PROTECTED] wrote: Hi All, I setup the osg2.0.0_vs71_setup_2007-06-19 version on my system but in include folder there is no osgViewer folder. Is it normal? I download 3rdPartyDependencies and osg2.0_vs71 but there is some problem about osgViewer include folder. So when I compile my program on VS2003, debugger alert me with 'fatal error C1083: Cannot open include file: 'osgViewer/Viewer': No such file or directory ' messages. Thanks so much. Yeah I noticed the same thing when I tried building against the OSG 2.0.0 prebuilt win32 binaries a long time ago, I'm guessing it was just a packaging bug. If you must have 2.0.0 you can probably solve it by downloading the header files for osgViewer from the OSG 2.0.0 source release and copying them to the proper location in your OSG prefix. I highly recommend just using OSG 2.4.0 instead though if you can. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] INSTALL include pdb's
On Thu, Jul 10, 2008 at 10:40 PM, James Killian [EMAIL PROTECTED] wrote: Hmmm no one has responded... I can figure out where in cmake to make the change, if I add it would anyone have any objections? (If no one responds... I'll assume its fine to add) I believe you'll want to have a look at the INSTALL(FILES...) and/or ADD_CUSTOM_COMMAND(TARGET foo POST_BUILD COMMAND) commands as possibilities. If you end up needing ADD_CUSTOM_COMMAND consider using cmake -E copy_if_different instead of copy. I'm out of town and don't have access to a VS development environment otherwise I think I could come up with something for you. This may also not be a bad feature to add to CMake itself if simply deploying the PDB files alongside the debug DLL file buys you this functionality. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quicktime osgplugin compile error with eclipse + mingw
On Thu, Jul 3, 2008 at 8:45 AM, Andrea Martini [EMAIL PROTECTED] wrote: Hi, i have used Robert's suggestion. I have added : #ifndef GL_BGRA_EXT #define GL_BGRA_EXT 0x80E1 #endif in MovieData.h. Previuos problem SOLVED. THANX :) Now i get another error : For each .h file in CInclude directory of QuickTime SDK folder, i get : warning: multi-character character constant and warning list ended with this error. mingw32-make[2]: *** [src/osgPlugins/quicktime/CMakeFiles/osgdb_qt.dir/MovieData.obj] Error 1 mingw32-make[1]: *** [src/osgPlugins/quicktime/CMakeFiles/osgdb_qt.dir/all] Error 2 mingw32-make: *** [all] Error 2 Can you run mingw32-make VERBOSE=1 and paste the entire output here from the last execution of gcc (i.e. the command that fails)? There should be a compilation error somewhere up above the warnings you're seeing if at the end it's erroring out. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quicktime osgplugin compile error with eclipse + mingw
On Fri, Jul 4, 2008 at 8:08 AM, Andrea Martini [EMAIL PROTECTED] wrote: Hi, i get 2 errors in tha last two line of log reported in : http://pastebin.com/m74380111 I have compiled with -Wno-multichar , but i still continue get the same warnings and error. Can you paste the entire output of mingw32-make VERBOSE=1 including stdout and stderr? -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quicktime osgplugin compile error with eclipse + mingw
On Thu, Jul 3, 2008 at 4:40 AM, Andrea Martini [EMAIL PROTECTED] wrote: Hi Philip, thank for your answer. I have searched gl.h include file in my fyle system, and i get this include file both in c:\mingw\include and visual studio path directory. Gl.h comes from visual studio directory contains the extension GL_BGRA_EXT and gl.h that comes from mingw has not. If i compile osg plugins with visual studio i have no problem. So i suppose that mingw must be updated with new opengl include and library. I have tried to use gl.h and glext.h from visual studio folder in mingw, but mingw gives me error! How i can update mingw to get the right gl extension? I have an nvidia quadro fx 4600 on window xp. I'm not sure. You might want to check with the MinGW people on this one. I have no idea why their gl.h doesn't expose the extension. If you get no resolution on this from them there is always the possibility of fixing this with a software workaround. I assume you actually need the quicktime plugin for something in your application? Another possibility is of course to simply disable building the quicktime plugin. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Determining supported file formats
On Thu, Jul 3, 2008 at 1:51 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Paul, I'm submitting this as a new application (rather than example) and calling it osgio. Thanks for this useful little utilitity. I do wonder if we could gather various functions together into a single application, something like osginfo, or osgconfig. For instance gdal has gldal-config: gdal-config Usage: gdal-config [OPTIONS] Options: [--prefix[=DIR]] [--libs] [--dep-libs] [--cflags] [--version] [--ogr-enabled] [--formats] Perhaps we could go the same route, and have CMake provide config details for it. This isn't a bad idea. It would certainly be useful for Linux users who would rather use automake or old-fashioned make itself to build osg binaries. What would --libs contain though? You could certainly make it contain all nodekits being built as part of the OSG as declared in CMake if that's what you're getting at (so you wouldn't have to update the list manually)? As for osgio, it might not be a bad idea to have it's functionality placed in an osg-config or osginfo type binary. Placing this kind of stuff in osgversion is probably a bad idea. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quicktime osgplugin compile error with eclipse + mingw
On Wed, Jul 2, 2008 at 4:23 AM, Andrea Martini [EMAIL PROTECTED] wrote: Hi guys, i have some problem when i try to compile quicktime osg plugin and openscenegraph 2.2.0. I'm going to compile openscenegraph 2.2.0 with minGW 3.14 and Eclipse 3.3.2 using CMake 2.6.0. I have downloaded quicktime SDK (version 7.1) and i have specified include and lib variables in CMAKE gui application. I'm using msys to compile openscenegraph, but at osgplugins QuickTime i get this error: O:\OpenSceneGraph-2.2.0\OpenSceneGraph\src\osgPlugins\quicktime\MovieData.cpp: In member function `void MovieData::_initImage(osg::Image*)': O:\OpenSceneGraph-2.2.0\OpenSceneGraph\src\osgPlugins\quicktime\MovieData.cpp:115: error: `GL_BGRA_EXT' was not declared in this scope mingw32-make[2]: *** [src/osgPlugins/quicktime/CMakeFiles/osgdb_qt.dir/MovieData.obj] Error 1 mingw32-make[1]: *** [src/osgPlugins/quicktime/CMakeFiles/osgdb_qt.dir/all] Error 2 mingw32-make: *** [all] Error 2 Could anyone gives me any suggestion? Some movies are apparantly encoded in BGRA instead of the more traditional RGBA format. My first thought is that the OpenGL header file you're including doesn't support the GL_EXT_bgra extension. See this webpage for some more details. It would be interesting to know what OpenGL extensions are not supported when compiling against a MinGW GL/gl.h http://www.opengl.org/resources/features/OGLextensions/ I believe you could work around this with a software patch by swapping the blue and red channels on the entire buffer. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.5 and cmake
On Wed, May 21, 2008 at 10:50 AM, [EMAIL PROTECTED] wrote: Sorry if this has come up before... I'm attempting to compile OSG 2.5 and when I do the ./configure, I get: CMake Error: Error in cmake code at /OSG_PATH/OSG_OP_OT-2.5/OpenSceneGraph-2.5.0/CMakeLists.txt:214: INCLUDE Could not find include file: FindPkgConfig Current CMake stack: /OSG_PATH/OSG_OP_OT-2.5/OpenSceneGraph-2.5.0/CMakeLists.txt;/OSG_PATH/cmake-2.4.6-Linux-i386/share/cmake-2.4/Modules/CMakeCInformation.cmake;/OSG_PATH/cmake-2.4.6-Linux-i386/share/cmake-2.4/Modules/CMakeCXXInformation.cmake;/OSG_PATH/OSG_OP_OT-2.5/OpenSceneGraph-2.5.0/FindPkgConfig CMake Error: Error in cmake code at /OSG_PATH/OSG_OP_OT-2.5/OpenSceneGraph-2.5.0/CMakeLists.txt:216: Unknown CMake command PKG_CHECK_MODULES. -- Configuring done When I look in the cmake 2.4.6 directory, I don't see a file called FindPkgConfig... However, if I look in CMAKE 2.6, I see such a file... The readme for OSG says it needs 2.4.6 or newer.. Did this requirement change. It seems that a change was made to CMakeLists.txt in early May which causes this include to now be used. This is a bug in OSG's build scripts. Since OSG is now using PKG_CHECK_MODULES (which was introduced in CMake 2.4.7) someone should either: 1. Bump CMAKE_MINIMUM_REQUIRED() to 2.4.7 at the top of the root CMakeLists.txt file to provide a more friendly warning for users that they need a newer version, or 2. Add checks around the usage of PKG_CHECK_MODULES. People using the older versions of CMake prior to 2.4.7 would not be able to link against the new dependencies but they would still be able to configure and build without error. FIND_PACKAGE(PkgConfig) IF(PKG_CONFIG_FOUND) # use pkg_check_modules() ENDIF(PKG_CONFIG_FOUND) -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.4 and Curl
On Thu, May 22, 2008 at 8:35 AM, Robert Osfield [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 1:17 PM, Philip Lowman [EMAIL PROTECTED] wrote: On Thu, May 22, 2008 at 7:30 AM, [EMAIL PROTECTED] wrote: I couldn't find these strings in the ccmake window (maybe I'm blind :-). Some of these strings may be under the advanced section of ccmake/cmakesetup. I've just checked, and the Find(CURL) only sets up CURL_INCLUDE_DIR and CURL_LIBRARY variables, there is also an CURL_IS_STATIC but that's created by OpenSceneGraph/CMakeLists.txt. So it looks like CMake built in CURL module doesn't set the version number :-| Most built in find modules for CMake don't go so far as to cache version numbers. The new interface for find_package() in 2.6.0 provides a mechanism for a caller to declare a minimum version they need which would be useful in a case like this, but few CMake find modules implement the version check. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Building the SVG plugin
On Tue, May 13, 2008 at 11:11 AM, Paul Martz [EMAIL PROTECTED] wrote: Hi Paul, As JS, Ulrich and Philip has mentioned at present the dependency checking code relies upon pkg-config, which isn't standard under Windows. For Windows we'll need write our won FindCario and FindRSVG.cmake files such as the ones we already have in OpenSceneGraph/CMakeModules. I was not aware that CMake offered multiple mechanisms for locating library dependencies. I have some questions about this; keep in mind I'm no CMake guru, so my questions might be stupid ones... Should OSG have some kind of policy regarding this so that third party dependencies are all located in a consistent manner? A quick check of the OSG CMake macros reveals that only GTK and rsvg/cario use the pkg config method, while all other third party dependencies are located using CMake Find scripts. Can GTK and rsvg/cairo be built under Visual Studio? Converting the OSG from using the pkg config macros to a Find module shouldn't be that much work. Have a look for Find*.cmake files in the OSG trunk and you'll have a pretty good idea what's involved. If there is no need for a policy of consistency, then how would someone determine the appropriate method for locating a dependency? In other words, suppose I made a OSG code change that required a new third party library; how would I decide what CMake location method is appropriate? I have seen CMake Find modules before that use pkg-config if it is available and if not fall back on locating the libraries manually using FIND_LIBRARY. Usually though it's not too much work just to convert everything to calling FIND_LIBRARY. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
