Re: [CMake] OpenSceneGraph Find Modules
On 12/12/07, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED] wrote: On Dec 10, 2007 9:40 AM, E. Wing wrote: snip That's all I can remember on Mac issues for the moment. But on a general CMake issue, I just submitted a whole bunch of Find*.cmake modules for inclusion. http://www.cmake.org/Bug/view.php?id=6139 Some of them are updates to existing modules that I have contributed. Others are brand new modules that I've been promising but needed to do significant clean up before submitting. (So that's where my weekend went.) FindFreeType.cmake FindGDAL.cmake FindGIFLIB.cmake FindLua50.cmake FindLua51.cmake FindOpenAL.cmake FindOpenSceneGraph.cmake FindOpenThreads.cmake FindPhysFS.cmake FindProducer.cmake FindQuickTime.cmake FindSDL.cmake FindSDL_image.cmake FindSDL_mixer.cmake FindSDL_net.cmake FindSDL_sound.cmake FindSDL_ttf.cmake Findosg.cmake FindosgDB.cmake FindosgFX.cmake FindosgGA.cmake FindosgIntrospection.cmake FindosgManipulator.cmake FindosgParticle.cmake FindosgProducer.cmake FindosgShadow.cmake FindosgSim.cmake FindosgTerrain.cmake FindosgText.cmake FindosgUtil.cmake FindosgViewer.cmake Hello Eric, I think these modules are a great addition to CMake. Thanks! However, I took a look at them and I'm concerned with uniformity with other modules. Now, I may be coming at it from a totally ignorant point of view, since I don't know any history behind them (e.g., I'll definitely not be aware of things that can't be changed do to backwards compatibility, etc.), so please take these suggestions with a grain of salt. I think that for packages that are external components of OSG, such as OpenGL, Producer, Quicktime, Lua, giflib, etc., there should be a separate module. However, all OSG components should be found in the same module (e.g., FindOpenSceneGraph.cmake). By having them separate it increases the maintainence burden, and people are more likely to get confused. If there are optional components, which you might or might not want to link in, you can use the COMPONENTS/REQUIRED interface of FIND_PACKAGE. For instance, the user would do something like: FIND_PACKAGE(OpenSceneGraph COMPONENTS DB FX GA Introspection) to use those particular modules only. That's the way I do it in the FindwxWidgets module. I suppose, you could also use the FindQt4 approach of having to set variables before calling the module (e.g., OSG_USE_DB, OSG_USE_FX, OSG_USE_GA, OSG_USE_INTROSPECTION). Furthermore, if you already build OSG using CMake (great choice btw ;) ), then you might prefer to request the CMake cache variable OpenSceneGraph_DIR to be set to the path of a file OpenSceneGraphConfig.cmake (take a look at: cmake --help-command find_package), where all the configuration options that where used for that particular OSG build can be found and so it is much user friendly to use the module. The user would do: FIND_PACKAGE(OpenSceneGraph) and by changing the location of the OpenSceneGraph_DIR variable all the correct (as defined by the OSG developers) options are set for that build. I'm interested in standardizing the cmake find modules and I would like to start using OpenSceneGraph some time soon for a course, so I'm willing to volunteer some testing and development time into these suggestions if you think they are reasonable and appropriate. Of course, making the changes before releasing them with CMake helps avoid backwards compatibility issues. Hope this helps, --Miguel Hi Miguel, So yes, there is a historical artifact involved in these modules. I actually wrote the core of these modules several years ago, and this is not my first submission attempt to CMake. (I think we paused on them because of significant changes in OSG, but the reality is that OSG continues to do that and I don't see an end in sight.) I know copies of my modules have floated around to people too, so there is at least a minor historical artifact involved. As for the bigger issue of a single FindOpenSceneGraph module vs sub-components, I have to disagree with you here. OSG was broken down into separate libraries by design to allow people to pick the components they want. The separate modules reflect this design in OSG. Furthermore, it's very difficult to decide what modules should be blessed in this all encompassing FindOpenSceneGraph module. There are several issues. First, OSG itself is a moving target and modules have come and go and some modules are somewhat optional and may have certain dependencies. For example, osgTerrain used to be optional and had a major dependency on GDAL. The GDAL dependency has been since removed, but I don't know if the usage of osgTerrain has increased. osgProducer used to be a very significant module but it is now been duplicated by osgViewer. osgProducer is being pushed aside, but a lot of people still use it. The other issue is that by OSG's intentional/original design, the
Re: [CMake] Re: Migration to subversion
On 12/22/07, Brandon Van Every [EMAIL PROTECTED] wrote: On Dec 22, 2007 6:48 PM, Andreas Schneider [EMAIL PROTECTED] wrote: Rodolfo Schulz de Lima wrote: That's great news. Since I've never been involved in a CVS - SVN migration, I couldn't help so much with it. Also, excuse me for assuming you weren't using svn and trying to sell it to you :) Before you switch to svn please use git. It's much better than the pain of cvs or svn. Mozilla is migrating to Mercurial. They rejected git; I forget why. It's early days for peer-to-peer source control, but based on my Darcs experience, in principle I'm a fan. My 2 cents. Distributed is the right way to go in my opinion. Git and Mercurial look like they have the most mindshare. I believe these will be the two dominant players by far in the coming years. I think Linus pointed to some scalability problems in Monotone and I think others have pointed to performance and memory usage problems with Bazaar (OpenSolaris?, Mozilla?). I haven't seen much mention of Darcs except for the 'dreaded exponential merge problem' and being written in Haskell making it harder to port. I would recommend going with either Git or Mercurial. However, the Windows story is currently pretty minimal with Git. I think Cygwin is still the best supported way to use Git on Windows, though I've read there is now a working Msys port. However, both of these options will be unacceptable to most Visual Studio users. With the CMake audience and funding being heavily slanted towards Visual Studio, I would say Git in its current state would be a bad decision for CMake. Until something like a 'TortoiseGit' appears and becomes usable/matures, I would rule out Git. That leaves Mercurial. They do seem to have a TortoiseHg with a 'batteries included' installer which makes it much more viable for the Windows story. From a user standpoint, Git and Mercurial are almost extremely similar in core interface and feature sets. Most of the differences seem to be implementation details. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Globally add compiler options for gcc
This is almost certainly a FAQ but I can't find an answer anywhere: I'm building using gcc under Linux and VS2005 under Win32. I want to add, say, -Wall globally to everything compiled under Linux but leave the compile options for Win32 untouched. How do I do that ? -- Regards Steve Collyer Netspinner Ltd ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] cmake 2.4.8 RC 9
Also missing the thread, I did want to chime in on a few things before it is left. First, Mike's pretty much nailed it on all points, though I think the use of installers needs to be qualified a little (below). As for where it is said not to install to /usr/bin, I don't know where in the docs, but Apple engineers every year at WWDC go up and say this. It's probably in the WWDC session videos on installers. Python has shipped with OS X for quite awhile as a standard component so Apple itself puts it in /usr/bin. I think DarwinPorts installs to /opt/local and Fink to /sw. This follows with Mike's arguments with separation and isolation. These will not be destroyed by Apple. Also, anybody using these will most likely use the tools own packaging system rather than install CMake through the installer, so these tools will ensure CMake is installed to their own appropriate locations. Finally, 'installers' are a controversial issue on Mac. Generally speaking, the old-school Mac (classic) people, and the elite OS X developers/users believe strongly that apps should be drag-and-droppable and not require installers. Applications should not have to live in any particular location on the filesystem and should just work no matter where they are. The security people and the anti-Windows people have also joined this bandwagon. Apple itself has been fuzzy and has waffled on the guidelines. For awhile, they were pushing drag-and-drop, but they would be hypocritical and use installers. However, the Mac elite will point out that Apple is the worst violator of their own Human/User Interface Guidelines so the funny thing is that Apple is not necessarily the authoritative voice on these issues. The Mac community is a little funny and many things seem to be dictated by its elite users and developers. Anyway, as far as CMake is concerned, because it deals with command line tools and a lot of stuff being installed in separate places, by Apple guidelines, an installer is an acceptable method of distributing CMake (presuming you don't install it to system areas). However, if you do distribute a GUI again, it would also be reasonable to consider a drag-and-droppable system where all CMake components are self-contained within the bundle. This would make the elite and security people happier. Mike has identified TextMate already. I think Doxygen and MacVim are also a little bit like this in that they avoid the installer and provide a self-contained drag-and-droppable bundle, though they not nearly as advanced as TextMate. (Both presume you know enough to add symlinks or shell-scripts or change your path to access tools in their bundles.) Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] MinGW detection question
I'm playing around with the MinGW generator. I was wondering if there is a special environmental variable that CMake will check for finding mingw32-make.exe. MinGW is not in my PATH so everytime I specify the MinGW generator in CMakeSetup, it complains it can't find the make program. I was hoping I could make CMake happy without adding more stuff to my PATH. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] MinGW detection question
CMake assumes the environment is setup to work. Just like with visual studio, you have to run vcvars.bat. Basically, cmake expects a working compiler, and can not modify the PATH. It can not modify the PATH because it won't be around when make is actually run. Actually, CMake did an excellent job building stuff without this in my PATH. Once I told CMakeSetup (manually) where the make program was, everything just worked. I presumed it was because you use explicit paths to everything to begin with. So all I needed was some other environmental variable to clue CMakeSetup about where the make program was, and things would be good. Also, I haven't needed vcvars.bat for Visual Studio. I never heard of it until now. I assumed that was because Visual Studio totally messed with my registry and system and CMake already knows how to deal with that. Thanks, Eric ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link commands from nmake
Uncomment the three lines at the bottom of Modules/Platform/Windows.cmake -- grep for CMAKE_START_TEMP_FILE to understand how the response file is constructed... HTH, David On 1/4/08, James Bigler [EMAIL PROTECTED] wrote: I'm using ICC and nmake to compile some code on Windows XP with the help of CMake 2.4.7. It's complaining that -L isn't supported. I want to see the link command, so that I can figure out which library is causing the problems. If I try to do nmake VERBOSE=1, I can see some of the output, but the actual command is hidden in a temporary file. If I look for that file, it's not there. Linking CXX shared library myLibrary.dll C:\Program Files\Programming\CMake 2.4\bin\cmake.exe -P CMakeFiles\LightNowForMaya.dir\cmake_clean_target.cmake link /nologo @C:\DOCUME~1\bigler\LOCALS~1\Temp\nm1C2.tmp Is there a way to see the commands passed to link or leave the file for my later inspection? Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Link commands from nmake
I'm using ICC and nmake to compile some code on Windows XP with the help of CMake 2.4.7. It's complaining that -L isn't supported. I want to see the link command, so that I can figure out which library is causing the problems. If I try to do nmake VERBOSE=1, I can see some of the output, but the actual command is hidden in a temporary file. If I look for that file, it's not there. Linking CXX shared library myLibrary.dll C:\Program Files\Programming\CMake 2.4\bin\cmake.exe -P CMakeFiles\LightNowForMaya.dir\cmake_clean_target.cmake link /nologo @C:\DOCUME~1\bigler\LOCALS~1\Temp\nm1C2.tmp Is there a way to see the commands passed to link or leave the file for my later inspection? Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Fwd: [CMake] Globally add compiler options for gcc
I did forget the list
-- Forwarded message --
From: Eric Noulard [EMAIL PROTECTED]
Date: 4 janv. 2008 18:33
Subject: Re: [CMake] Globally add compiler options for gcc
To: Stephen Collyer [EMAIL PROTECTED]
2008/1/4, Stephen Collyer [EMAIL PROTECTED]:
This is almost certainly a FAQ but I can't find
an answer anywhere: I'm building using gcc under
Linux and VS2005 under Win32. I want to add, say,
-Wall globally to everything compiled under Linux
but leave the compile options for Win32 untouched.
You may put in your main CMakeLists.txt
IF(UNIX)
IF(CMAKE_COMPILER_IS_GNUCC)
ADD_DEFINITION(-Wall)
ENDIF(CMAKE_COMPILER_IS_GNUCC)
ENDIF(UNIX)
This example checks for being under UNIX and GCC is the compiler.
If you want to restrict to Linux you should add a test
for CMAKE_SYSTEM_NAME value to match Linux.
In this particular case and if you only compile C code
you may replace ADD_DEFINITIONS with:
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Wall)
If you want more stringent checks
you add -Werror -pedantic -ansi to your -Wall :=)
How do I do that ?
--
Regards
Steve Collyer
Netspinner Ltd
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Erk
--
Erk
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: Fwd: [CMake] Globally add compiler options for gcc
On Friday 04 January 2008, James Bigler wrote:
2008/1/4, Stephen Collyer [EMAIL PROTECTED]:
This is almost certainly a FAQ but I can't find
an answer anywhere: I'm building using gcc under
Linux and VS2005 under Win32. I want to add, say,
-Wall globally to everything compiled under Linux
but leave the compile options for Win32 untouched.
You may put in your main CMakeLists.txt
IF(UNIX)
IF(CMAKE_COMPILER_IS_GNUCC)
ADD_DEFINITION(-Wall)
ENDIF(CMAKE_COMPILER_IS_GNUCC)
ENDIF(UNIX)
This example checks for being under UNIX and GCC is the compiler.
If you want to restrict to Linux you should add a test
for CMAKE_SYSTEM_NAME value to match Linux.
In this particular case and if you only compile C code
you may replace ADD_DEFINITIONS with:
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Wall)
Doing it this way will most certainly give you grief, unless you add bit
more infrastructure. First off, every time you run cmake, it will add
another -Wall to your CMAKE_C_FLAGS. Also, I'm a little unsure of this,
but it may not even set the flags properly without a FORCE in the
command. Also, you will find it hard for a user to turn it off if they
don't wish to see it for some reason.
No, I think you are wrong here, it does work.
What happens is:
CMAKE_C_FLAGS is read from the cache, e.g. -O2 -ansi
Then the set happens and appends the -Wall, so CMAKE_C_FLAGS is now
-O2 -ansi -Wall
This new value isn't saved to the cache, but stays only in the regular cmake
variable. To get it in the cache SET(... CACHE ... FORCE) would have to be
used. Only then it would be appended everytime again.
Alex
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Globally add compiler options for gcc
On Jan 4, 2008, at 10:57 AM, Alexander Neundorf wrote:
On Friday 04 January 2008, James Bigler wrote:
2008/1/4, Stephen Collyer [EMAIL PROTECTED]:
This is almost certainly a FAQ but I can't find
an answer anywhere: I'm building using gcc under
Linux and VS2005 under Win32. I want to add, say,
-Wall globally to everything compiled under Linux
but leave the compile options for Win32 untouched.
You may put in your main CMakeLists.txt
IF(UNIX)
IF(CMAKE_COMPILER_IS_GNUCC)
ADD_DEFINITION(-Wall)
ENDIF(CMAKE_COMPILER_IS_GNUCC)
ENDIF(UNIX)
This example checks for being under UNIX and GCC is the compiler.
If you want to restrict to Linux you should add a test
for CMAKE_SYSTEM_NAME value to match Linux.
In this particular case and if you only compile C code
you may replace ADD_DEFINITIONS with:
SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -Wall)
Doing it this way will most certainly give you grief, unless you
add bit
more infrastructure. First off, every time you run cmake, it will
add
another -Wall to your CMAKE_C_FLAGS. Also, I'm a little unsure of
this,
but it may not even set the flags properly without a FORCE in the
command. Also, you will find it hard for a user to turn it off if
they
don't wish to see it for some reason.
No, I think you are wrong here, it does work.
What happens is:
CMAKE_C_FLAGS is read from the cache, e.g. -O2 -ansi
Then the set happens and appends the -Wall, so CMAKE_C_FLAGS is now
-O2 -ansi -Wall
This new value isn't saved to the cache, but stays only in the
regular cmake
variable. To get it in the cache SET(... CACHE ... FORCE) would
have to be
used. Only then it would be appended everytime again.
I had suspisions that this was how that bit of code worked, so thanks
for clearing this up for me.
There's still the outstanding issue of a flag being added that the
user can't control (and may get irritated at), but perhaps a new
cached CMake variable could be added to turn the warnings on and off.
James
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Globally add compiler options for gcc
2008/1/4, James Bigler [EMAIL PROTECTED]: On Jan 4, 2008, at 10:57 AM, Alexander Neundorf wrote: No, I think you are wrong here, it does work. What happens is: CMAKE_C_FLAGS is read from the cache, e.g. -O2 -ansi Then the set happens and appends the -Wall, so CMAKE_C_FLAGS is now -O2 -ansi -Wall This new value isn't saved to the cache, but stays only in the regular cmake variable. To get it in the cache SET(... CACHE ... FORCE) would have to be used. Only then it would be appended everytime again. I had suspisions that this was how that bit of code worked, so thanks for clearing this up for me. Thanks you from my side too Alex. I was wondering why it seems to work for me and was ready test in order to seek where I missed the point :=) You saved me time. There's still the outstanding issue of a flag being added that the user can't control (and may get irritated at), but perhaps a new cached CMake variable could be added to turn the warnings on and off. Yes you are right or one may add an OPTION in order to control this kind of extra flags. Note that one usually add a global -Wall in order to _FIX_ all the phony warnings before release. Once you do not have any warning you won't irritate your user :=) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link commands from nmake
Not to my knowledge... I don't use nmake very often, though. Maybe something changed since the last time I did that... Send along some of the output of nmake after you made those changes... Does it still say it's using a *.tmp file for the link step? On 1/4/08, James Bigler [EMAIL PROTECTED] wrote: Hmm... I uncommented out those lines, but it didn't seem to have an effect. I even started with a new build directory. Was there something else I was supposed to edit? James On Jan 4, 2008, at 11:03 AM, David Cole wrote: Uncomment the three lines at the bottom of Modules/Platform/ Windows.cmake -- grep for CMAKE_START_TEMP_FILE to understand how the response file is constructed... HTH, David On 1/4/08, James Bigler [EMAIL PROTECTED] wrote: I'm using ICC and nmake to compile some code on Windows XP with the help of CMake 2.4.7. It's complaining that -L isn't supported. I want to see the link command, so that I can figure out which library is causing the problems. If I try to do nmake VERBOSE=1, I can see some of the output, but the actual command is hidden in a temporary file. If I look for that file, it's not there. Linking CXX shared library myLibrary.dll C:\Program Files\Programming\CMake 2.4\bin\cmake.exe -P CMakeFiles\LightNowForMaya.dir\cmake_clean_target.cmake link /nologo @C:\DOCUME~1\bigler\LOCALS~1\Temp\nm1C2.tmp Is there a way to see the commands passed to link or leave the file for my later inspection? Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
Hi Eric and Miguel, It would be good to have the OSG-related modules inside CMake, both modules for finding OSG dependencies as well as finding OSG itself when needed by other projects. I agree with all the suggestion of Miguel, expecially the idea of using OpenSceneGraph_DIR and OpenSceneGraphConfig.cmake: OSG current build system is CMake, so I think that using OpenSceneGraphConfig.cmake and adding some useful macros to the base OSG install would help in building simple projects that rely mainly on OSG (like new plugins or new examples) I would also prefer to have one single FindOpenSceneGraph that finds and configure the different libraries that comprise OSG. It also seems to me that having so many Findosg.. modules distributed with CMake pose some scalability issue if many projects adopt CMake Just my two cents Luigi E. Wing wrote: On 12/12/07, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED] wrote: On Dec 10, 2007 9:40 AM, E. Wing wrote: snip That's all I can remember on Mac issues for the moment. But on a general CMake issue, I just submitted a whole bunch of Find*.cmake modules for inclusion. http://www.cmake.org/Bug/view.php?id=6139 Some of them are updates to existing modules that I have contributed. Others are brand new modules that I've been promising but needed to do significant clean up before submitting. (So that's where my weekend went.) FindFreeType.cmake FindGDAL.cmake FindGIFLIB.cmake FindLua50.cmake FindLua51.cmake FindOpenAL.cmake FindOpenSceneGraph.cmake FindOpenThreads.cmake FindPhysFS.cmake FindProducer.cmake FindQuickTime.cmake FindSDL.cmake FindSDL_image.cmake FindSDL_mixer.cmake FindSDL_net.cmake FindSDL_sound.cmake FindSDL_ttf.cmake Findosg.cmake FindosgDB.cmake FindosgFX.cmake FindosgGA.cmake FindosgIntrospection.cmake FindosgManipulator.cmake FindosgParticle.cmake FindosgProducer.cmake FindosgShadow.cmake FindosgSim.cmake FindosgTerrain.cmake FindosgText.cmake FindosgUtil.cmake FindosgViewer.cmake Hello Eric, I think these modules are a great addition to CMake. Thanks! However, I took a look at them and I'm concerned with uniformity with other modules. Now, I may be coming at it from a totally ignorant point of view, since I don't know any history behind them (e.g., I'll definitely not be aware of things that can't be changed do to backwards compatibility, etc.), so please take these suggestions with a grain of salt. I think that for packages that are external components of OSG, such as OpenGL, Producer, Quicktime, Lua, giflib, etc., there should be a separate module. However, all OSG components should be found in the same module (e.g., FindOpenSceneGraph.cmake). By having them separate it increases the maintainence burden, and people are more likely to get confused. If there are optional components, which you might or might not want to link in, you can use the COMPONENTS/REQUIRED interface of FIND_PACKAGE. For instance, the user would do something like: FIND_PACKAGE(OpenSceneGraph COMPONENTS DB FX GA Introspection) to use those particular modules only. That's the way I do it in the FindwxWidgets module. I suppose, you could also use the FindQt4 approach of having to set variables before calling the module (e.g., OSG_USE_DB, OSG_USE_FX, OSG_USE_GA, OSG_USE_INTROSPECTION). Furthermore, if you already build OSG using CMake (great choice btw ;) ), then you might prefer to request the CMake cache variable OpenSceneGraph_DIR to be set to the path of a file OpenSceneGraphConfig.cmake (take a look at: cmake --help-command find_package), where all the configuration options that where used for that particular OSG build can be found and so it is much user friendly to use the module. The user would do: FIND_PACKAGE(OpenSceneGraph) and by changing the location of the OpenSceneGraph_DIR variable all the correct (as defined by the OSG developers) options are set for that build. I'm interested in standardizing the cmake find modules and I would like to start using OpenSceneGraph some time soon for a course, so I'm willing to volunteer some testing and development time into these suggestions if you think they are reasonable and appropriate. Of course, making the changes before releasing them with CMake helps avoid backwards compatibility issues. Hope this helps, --Miguel Hi Miguel, So yes, there is a historical artifact involved in these modules. I actually wrote the core of these modules several years ago, and this is not my first submission attempt to CMake. (I think we paused on them because of significant changes in OSG, but the reality is that OSG continues to do that and I don't see an end in sight.) I know copies of my modules have floated around to people too, so there is at least a minor historical artifact involved. As for the bigger issue of a single FindOpenSceneGraph module vs sub-components, I have to disagree with you here. OSG was broken down into separate libraries by design to allow people to pick the components they want. The
Re: [CMake] Link commands from nmake
Hmm... I uncommented out those lines, but it didn't seem to have an effect. I even started with a new build directory. Was there something else I was supposed to edit? James On Jan 4, 2008, at 11:03 AM, David Cole wrote: Uncomment the three lines at the bottom of Modules/Platform/ Windows.cmake -- grep for CMAKE_START_TEMP_FILE to understand how the response file is constructed... HTH, David On 1/4/08, James Bigler [EMAIL PROTECTED] wrote: I'm using ICC and nmake to compile some code on Windows XP with the help of CMake 2.4.7. It's complaining that -L isn't supported. I want to see the link command, so that I can figure out which library is causing the problems. If I try to do nmake VERBOSE=1, I can see some of the output, but the actual command is hidden in a temporary file. If I look for that file, it's not there. Linking CXX shared library myLibrary.dll C:\Program Files\Programming\CMake 2.4\bin\cmake.exe -P CMakeFiles\LightNowForMaya.dir\cmake_clean_target.cmake link /nologo @C:\DOCUME~1\bigler\LOCALS~1\Temp\nm1C2.tmp Is there a way to see the commands passed to link or leave the file for my later inspection? Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 4, 2008 10:17 AM, E. Wing [EMAIL PROTECTED] wrote: I think Linus pointed to some scalability problems in Monotone and I think others have pointed to performance and memory usage problems with Bazaar (OpenSolaris?, Mozilla?). I don't know what they tried before, but Mozilla is a Mercurial shop now. I haven't seen much mention of Darcs except for the 'dreaded exponential merge problem' and being written in Haskell making it harder to port. My $0.02 is Darcs is easy to use. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
On Jan 4, 2008 2:09 PM, Luigi Calori [EMAIL PROTECTED] wrote: I would also prefer to have one single FindOpenSceneGraph that finds and configure the different libraries that comprise OSG. Such an attitude can carry a strong Linux bias. I ran into that difficulty with Chicken Scheme when importing SDL modules. The SDL import was monolithic, pulling in lotsa 3rd party packages that are typically used with SDL but not strictly required. If any of the packages is missing the build breaks. I don't mean gracefully excludes an unavailable package, I mean it keels over and dies. This doesn't trouble Linux users because they typically press a few buttons and start downloading standardized, well-tested packages. Including everything and the kitchen sink isn't a big deal to a Linux user. But for a Windows user, there simply aren't colossal standard archives of libraries floating around. Every dependency has to be grabbed by hand. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
On Jan 4, 2008 3:23 PM, Brandon Van Every wrote: On Jan 4, 2008 2:09 PM, Luigi Calori wrote: I would also prefer to have one single FindOpenSceneGraph that finds and configure the different libraries that comprise OSG. Such an attitude can carry a strong Linux bias. I ran into that difficulty with Chicken Scheme when importing SDL modules. The SDL import was monolithic, pulling in lotsa 3rd party packages that are typically used with SDL but not strictly required. If any of the packages is missing the build breaks. I don't mean gracefully excludes an unavailable package, I mean it keels over and dies. This doesn't trouble Linux users because they typically press a few buttons and start downloading standardized, well-tested packages. Including everything and the kitchen sink isn't a big deal to a Linux user. But for a Windows user, there simply aren't colossal standard archives of libraries floating around. Every dependency has to be grabbed by hand. Hello Brandon, I'm kind of lost here with your argument. If I get it wrong, please just clarify it. I don't think this carries the bias you present. The idea is not to force the user to have all packages installed if they are optional. The module should only fail if a *required* package is not found. If the SDL module was poorly designed in that sense, then it needs some enhancements. What I was suggesting is that instead of having the following modules separate: Findosg.cmake FindosgDB.cmake FindosgFX.cmake FindosgGA.cmake FindosgIntrospection.cmake FindosgManipulator.cmake FindosgParticle.cmake FindosgProducer.cmake FindosgShadow.cmake FindosgSim.cmake FindosgTerrain.cmake FindosgText.cmake FindosgUtil.cmake FindosgViewer.cmake You should have a single FindOpenSceneGraph.cmake module and provide a mechanism to use (if available) the different components of the library (FX, GA, Introspection, etc.) that the user is interested in. --Miguel ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Link commands from nmake
David Cole wrote: Not to my knowledge... I don't use nmake very often, though. Maybe something changed since the last time I did that... Send along some of the output of nmake after you made those changes... Does it still say it's using a *.tmp file for the link step? Linking CXX shared library myLib.dll C:\Program Files\Programming\CMake 2.4\bin\cmake.exe -P CMakeFiles\myLib.dir\cmake_clean_target.cmake link /nologo @C:\DOCUME~1\bigler\LOCALS~1\Temp\nm236.tmp link: invalid option -- L So, it looks like it is still using the n*.tmp file. This is why I asked if there was other code I needed to modify. James On 1/4/08, James Bigler [EMAIL PROTECTED] wrote: Hmm... I uncommented out those lines, but it didn't seem to have an effect. I even started with a new build directory. Was there something else I was supposed to edit? James On Jan 4, 2008, at 11:03 AM, David Cole wrote: Uncomment the three lines at the bottom of Modules/Platform/ Windows.cmake -- grep for CMAKE_START_TEMP_FILE to understand how the response file is constructed... HTH, David On 1/4/08, James Bigler [EMAIL PROTECTED] wrote: I'm using ICC and nmake to compile some code on Windows XP with the help of CMake 2.4.7. It's complaining that -L isn't supported. I want to see the link command, so that I can figure out which library is causing the problems. If I try to do nmake VERBOSE=1, I can see some of the output, but the actual command is hidden in a temporary file. If I look for that file, it's not there. Linking CXX shared library myLibrary.dll C:\Program Files\Programming\CMake 2.4\bin\cmake.exe -P CMakeFiles\LightNowForMaya.dir\cmake_clean_target.cmake link /nologo @C:\DOCUME~1\bigler\LOCALS~1\Temp\nm1C2.tmp Is there a way to see the commands passed to link or leave the file for my later inspection? Thanks, James ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On 2008-01-04 07:17-0800 E. Wing wrote: My 2 cents. Distributed [version control system] is the right way to go in my opinion. I don't completely agree. Centralized repositories have proved useful for lots of software development projects (e.g., the 160,000+ free software projects at SourceForge). Of course, centralized repos don't work very well if projects (such as the Linux kernel) have huge numbers of active developers, but most software projects (such as CMake) will never have more than a handful of active developers, and for such projects a centralized repository makes a lot of sense. Thus, it is probably a given that CMake will always use a centralized repository. I assume that does not rule out git or Mercurial. For example, from the git-svn crash course at http://git.or.cz/course/svn.html, it appears that git has the capability to use a centralized repository (the so-called bare repository), and I presume that is the case for Mercurial as well. So the choice between cvs, svn, git, and Mercurial really boils down to how impressed the CMake developers are with the particular implementation of a version control system with a centralized repository. My own personal experience has been I used CVS for years (at first because that was all that was available at SF, but then after they deployed the svn alternative there it was just inertia even though there were many aspects of cvs I did not like). However, last year I participated in one project that used svn, and that nice experience convinced me rather quickly to switch all my projects to svn because cvs just sucks in comparison with svn. Currently, I am almost completely satisfied with svn, and I think it would be an excellent choice for CMake as well. However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
Quoting Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]: What I was suggesting is that instead of having the following modules separate: Findosg.cmake FindosgDB.cmake FindosgFX.cmake FindosgGA.cmake FindosgIntrospection.cmake FindosgManipulator.cmake FindosgParticle.cmake FindosgProducer.cmake FindosgShadow.cmake FindosgSim.cmake FindosgTerrain.cmake FindosgText.cmake FindosgUtil.cmake FindosgViewer.cmake You should have a single FindOpenSceneGraph.cmake module and provide a mechanism to use (if available) the different components of the library (FX, GA, Introspection, etc.) that the user is interested in. I'm doing somethink like that for ZeroC ICE. ICE has several libraries (IceCore, IceBox, IceGrid, IcePatch2, IceSSL, IceStorm, IceUtil, IceXML, Freeze, Glacier2 and some executables). I have a Find.cmake for each of them: FindZeroCIceBox.cmake FindZeroCIceCore.cmake FindZeroCIceExecutables.cmake FindZeroCIceGrid.cmake FindZeroCIcePatch2.cmake FindZeroCIceSSL.cmake FindZeroCIceStorm.cmake FindZeroCIceUtil.cmake FindZeroCIceXML.cmake FindZeroCFreeze.cmake FindZeroCGlacier2.cmake Then I have a FindZeroCIce.cmake which essentially has this code: [...] SET( ZeroCIceCore_FIND_QUIETLY TRUE ) SET( ZeroCIceBox_FIND_QUIETLY TRUE ) SET( ZeroCIceGrid_FIND_QUIETLY TRUE ) SET( ZeroCIcePatch2_FIND_QUIETLY TRUE ) SET( ZeroCIceSSL_FIND_QUIETLY TRUE ) SET( ZeroCIceStorm_FIND_QUIETLY TRUE ) SET( ZeroCIceUtil_FIND_QUIETLY TRUE ) SET( ZeroCIceXML_FIND_QUIETLY TRUE ) SET( ZeroCIceExecutables_FIND_QUIETLY TRUE ) SET( ZeroCIceFreeze_FIND_QUIETLY TRUE ) SET( ZeroCIceGlacier2_FIND_QUIETLY TRUE ) FIND_PACKAGE( ZeroCIceCore ) FIND_PACKAGE( ZeroCIceBox ) FIND_PACKAGE( ZeroCIceGrid ) FIND_PACKAGE( ZeroCIcePatch2 ) FIND_PACKAGE( ZeroCIceSSL ) FIND_PACKAGE( ZeroCIceStorm ) FIND_PACKAGE( ZeroCIceUtil ) FIND_PACKAGE( ZeroCIceXML ) FIND_PACKAGE( ZeroCIceExecutables ) FIND_PACKAGE( ZeroCIceFreeze ) FIND_PACKAGE( ZeroCIceGlacier2 ) [...] If a project only needs a couple of libraries, say IceCore and IceUtil, I just do: FIND_PACKAGE( ZeroCIceCore) FIND_PACKAGE( ZeroCIceUtil) But if I'm going to need most or all of ICE, I just do FIND_PACKAGE( ZeroCIce ) and now I have all the variables set. Would that be acceptable for OSG? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: Migration to subversion
Alan W. Irwin wrote: developers, but most software projects (such as CMake) will never have more than a handful of active developers cmake already has about 10-20 or so developers (if you consider all the .cmake module contributions). People with commit access, however, are much fewer right now. I assume that does not rule out git or Mercurial. For example, from the git-svn crash course at http://git.or.cz/course/svn.html, it appears that git has the capability to use a centralized repository (the so-called bare repository), and I presume that is the case for Mercurial as well. Not really. Both git and Mercurial are always distributed. You can have one official repository but you cannot prevent people from cloning it. However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? See Linus presentation at google (available on youtube). But basically, with git you get: * Faster and smaller repositories. A git repository will often be 1/3rd of an equivalent cvs or svn one. * git guarantees that what you put in the repository is what you get out. All commits are SHA1 verified. CVS and SVN have no verification. If disk corruption happens or a malicious user fakes a file or screws up, say, the ,v files, you can get garbage out without anyone noticing. * git offers two apis (one for high level user access and one for low level admin/script access similar to using tricks in cvs like hacking the ,v files). * Branches and merging are native to the repository. Both can be done in linear time (and probably) with much less chance of conflicts. * Distributed. You can work with the repository without being connected (on a plane or laptop, for example) and then merge later. * Distributed allows you to much more easily mix and match from several repositories of trusted persons, to create your own flavor of code. For example, Linus is not an expert in networking, but he can easily fetch and merge network changes from other developers that are, once they verified the code (thus, reducing the amount of work *he* has to do on things he is not really an expert on). A central repository makes it much more easy for the changes of the two developers to overlap or screw up the build of the other person while developing. Or the developer just has to never commit, until all your tests pass and your changes are done. * git offers bisect options in linear time. It becomes trivial to find a line commit that screwed up something. There's nothing like that on CVS or SVN, where it has to be done manually. And even then, it is not linear. * git patches can be created to be easy to email for those that have no write access. * git has proven scalability (for both git and the kernel, probably some of the largest per day/month commit base of any known projects). With Mercurial you get the same except faster and smaller and only a single api. It is at least 40% slower than git in my (short) experience. Monotone offers better verification but much, much slower performance. In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Mike Jackson wrote: http://www.youtube.com/watch?v=4XpnKHJAok8 Git - straight from Linus. I have this strange preference for my own voice and personality :-) http://video.google.com/videoplay?docid=-7724296011317502612 b ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
Am Freitag 04 Januar 2008 schrieb Pau Garcia i Quiles:
Quoting Miguel A. Figueroa-Villanueva [EMAIL PROTECTED]:
What I was suggesting is that instead of having the following
modules separate:
Findosg.cmake
FindosgDB.cmake
FindosgFX.cmake
FindosgGA.cmake
FindosgIntrospection.cmake
FindosgManipulator.cmake
FindosgParticle.cmake
FindosgProducer.cmake
FindosgShadow.cmake
FindosgSim.cmake
FindosgTerrain.cmake
FindosgText.cmake
FindosgUtil.cmake
FindosgViewer.cmake
You should have a single FindOpenSceneGraph.cmake module and provide a
mechanism to use (if available) the different components of the
library (FX, GA, Introspection, etc.) that the user is interested in.
I'm doing somethink like that for ZeroC ICE.
ICE has several libraries (IceCore, IceBox, IceGrid, IcePatch2,
IceSSL, IceStorm, IceUtil, IceXML, Freeze, Glacier2 and some
executables). I have a Find.cmake for each of them:
FindZeroCIceBox.cmake
FindZeroCIceCore.cmake
FindZeroCIceExecutables.cmake
FindZeroCIceGrid.cmake
FindZeroCIcePatch2.cmake
FindZeroCIceSSL.cmake
FindZeroCIceStorm.cmake
FindZeroCIceUtil.cmake
FindZeroCIceXML.cmake
FindZeroCFreeze.cmake
FindZeroCGlacier2.cmake
Then I have a FindZeroCIce.cmake which essentially has this code:
[...]
SET( ZeroCIceCore_FIND_QUIETLY TRUE )
SET( ZeroCIceBox_FIND_QUIETLY TRUE )
SET( ZeroCIceGrid_FIND_QUIETLY TRUE )
SET( ZeroCIcePatch2_FIND_QUIETLY TRUE )
SET( ZeroCIceSSL_FIND_QUIETLY TRUE )
SET( ZeroCIceStorm_FIND_QUIETLY TRUE )
SET( ZeroCIceUtil_FIND_QUIETLY TRUE )
SET( ZeroCIceXML_FIND_QUIETLY TRUE )
SET( ZeroCIceExecutables_FIND_QUIETLY TRUE )
SET( ZeroCIceFreeze_FIND_QUIETLY TRUE )
SET( ZeroCIceGlacier2_FIND_QUIETLY TRUE )
FIND_PACKAGE( ZeroCIceCore )
or simpler:
foreach ( i Core Box Grid Patch2)
set ( ZeroCIce${i}_FIND_QUIETLY TRUE )
find_package ( ZeroCIce${i} )
endforeach ( i )
That's not really worth a seperate module file.
Maybe a scheme for module subdirectories should be created and added to CMake?
There are probably plenty of such projects that are splitted into numerous
sub-parts. A
find_package ( ZeroCIce COMPONENTS Core Box )
could then automatically resolv to the above two parts but for the module
files:
FindZeroCIce/Core.cmake and
FindZeroCIce/Box.cmake
If that cannot be included into CMake, such modules could include the files in
the subdir and evaluate the COMPONENTS themselves in a FindZeroCIce.cmake.
IMHO using a subdirectory is way better than putting everything in the file
name because at one point, the directory listing of the modules directory
will not be readable anymore :-(
OTOH, ask yourself if such modules do more than being a wrapper around
find_library because there is no need for such (creating a module for every
lib out there is insane).
HS
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
Alan W. Irwin wrote: However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? A significant difference is completely offline operation. With a centralised tool, by definition you can't commit if you're not on the network. With a distributed tool, committing changes is decoupled from sharing them. As you surmise, you can agree to use a central repository with a distributed tool, but it's a matter of preference and convention, not something forced upon you by the tool designers. b ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
http://www.youtube.com/watch?v=4XpnKHJAok8 Git - straight from Linus.. Kinda long but interesting.. as long as you can get past Linus' personality. Mike On Jan 4, 2008 4:11 PM, Bryan O'Sullivan [EMAIL PROTECTED] wrote: Alan W. Irwin wrote: However, I admit to having no development experience with git or Mercurial. Is there anything compelling (e.g., fewer bugs, better documentation, more useful features aside from distributed?) about either over svn for projects like CMake that use a centralized repo? A significant difference is completely offline operation. With a centralised tool, by definition you can't commit if you're not on the network. With a distributed tool, committing changes is decoupled from sharing them. As you surmise, you can agree to use a central repository with a distributed tool, but it's a matter of preference and convention, not something forced upon you by the tool designers. b ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- Mike Jackson imikejackson _at_ gee-mail dot com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
On Jan 4, 2008 3:50 PM, Alan W. Irwin [EMAIL PROTECTED] wrote: On 2008-01-04 07:17-0800 E. Wing wrote: My 2 cents. Distributed [version control system] is the right way to go in my opinion. I don't completely agree. Centralized repositories have proved useful for lots of software development projects (e.g., the 160,000+ free software projects at SourceForge). Of course, centralized repos don't work very well if projects (such as the Linux kernel) have huge numbers of active developers, but most software projects (such as CMake) will never have more than a handful of active developers, and for such projects a centralized repository makes a lot of sense. Why? Other than it's what you're used to. When I was doing Chicken Scheme, we had very few people banging on the Darcs source repository, but nevertheless it was useful to our work. Typically we could just work past each other and not worry about merges. Thus, it is probably a given that CMake will always use a centralized repository. You haven't even begun to prove a thus. What is so important about being centralized? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
On Jan 4, 2008 3:09 PM, Miguel A. Figueroa-Villanueva [EMAIL PROTECTED] wrote: I don't think this carries the bias you present. The idea is not to force the user to have all packages installed if they are optional. The module should only fail if a *required* package is not found. If the SDL module was poorly designed in that sense, then it needs some enhancements. Indeed the Chicken SDL package did need such enhancements. But they were not performed, because in the real world it's extra implementation labor to chase the changing components around. As you say, the problem is solvable in principle. In practice, whether it gets solved depends on the level of energy of the FindOSG maintainer. In this thread we've heard that he feels a bit, ah, overwhelmed by the scope of OSG, so I have my doubts that a monolithic FindOSG is going to function correctly over time. Perhaps the answer is for you and others to join forces with him so that it isn't 1 person being overwhelmed by the gruntwork. Chicken SDL packaging didn't improve much because the people who did tend to use it were Linuxers, and nobody wanted to be saddled with sole responsibility for the needed improvements. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: Migration to subversion
Gonzalo Garramuño wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
- Original Message - From: James Mansion Date: 1/4/2008 3:38 PM Gonzalo Garramuño wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? Pretty well, I've found, using http://code.google.com/p/msysgit/ I've spent the past couple weeks looking (again) heavily into Bazaar, Git, and Mercurial. Let me see if I can recap some of my positive and negative experiences, bearing in mind I'm a Windows user. Let me start by saying they all seem to work reasonably well and are all distributed. Bazaar: * Pro: I love the lightweight checkout support from a central repository. For games with gigabytes of assets, storing the history locally for all those assets is often unreasonable. Lightweight checkouts provide a direct connection to the server and work almost exactly like Subversion/Perforce. * Pro: For a checkout, I can bzr unbind it and commit locally only. Nice. * Pro: Bazaar has a smart server built in. I set it up and had it running over an Stunnel client certificate connection in no time. No need to set up an SSH server for pushes! Yeah! * Pro/Con: Branches are directories and can be switched in place or used as a separate tree. * Con: No authentication for the smart server. Blech. * Con: Bazaar for Win32 requires a patch or initial large bzr branch operations fail. Ironically, I got the one line patch from their own bug database. It just isn't integrated yet. * Con: Initial bzr branches take much longer than Git. * Con: No visuals during branch, push, or pull operations to show me how the network transfer is going. * Con: Bazaar seems to eat 100% of the CPU time when performing its operations. * Con: No submodule/subproject support. Git: * This one is much different than any other version control system I've used. This may be good or bad. I don't know. My curiosity is piqued enough to fight things like the SSH support. * Pro: When cloning a local repository, you can get the secondary repository to refer to the heavyweight content in the initial repository, thereby saving disk space. * Pro: As far as GUIs go for all 3, QGit is one of the better ones. It still doesn't compare to a complete tool like P4V/P4Win. * Pro: Has submodule support built in now. This means I can put n different repositories in a hierarchy and have it mostly treat the whole tree as one repository. There is still some work to be done here, but it is definitely a big deal. * Pro: Shows progress on clones. * Pro/Con: Branches are named and switched in place. * Pro/Con: Has the ability to create a shallow clone without all the history. Unfortunately, the clone is mostly useless for development. * Con: The local repository clone space savings only applies to local repositories. There is no equivalent of the Bazaar lightweight checkout from the server repository. * Con: Requires an SSH daemon to push data. I just barely got this going (through copSSH) with the replacement git-shell, because I don't want people to have shell access to my machine. Locking down user permissions and directories on a Windows box stinks. I've got to see about setting up the SSH authorized keys. * Con: msysgit doesn't come with git-daemon, but git-daemon is for read-only, pull access anyway. Mercurial: * Pro: Seems reasonably fast. * Pro: Has an access control list extension. * Pro/Con: Branches are named and switched in place. * Con: No lightweight clones of repositories. Unix hardlinks don't count. * Con: The hgwebdir.cgi was a pain to set up, and it doesn't support client certificates over https. Boo! * Con: I can't figure out how to get the SSH support working. It just hangs, and hg -v --debug is not that helpful. * Con: The submodule support through the Forest extension feels incomplete. svk: * Pro: Has an ultra cool svk sync -s HEAD command that starts your repository from the latest with no back history. If I sat down with this longer, I'm sure I could really flesh these lists out. Josh ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [Spam] Re: [CMake] Re: Migration to subversion
On 2008-01-04 22:38- James Mansion wrote: Gonzalo Garramu�o wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? As already mentioned earlier in this thread, git is available for Cygwin (see http://cygwin.com/packages/git/), and for those who prefer the MinGW development environment, I just now discovered a git version that apparently can be built using MinGW (see http://repo.or.cz/w/git/mingw.git and http://repo.or.cz/w/git/mingw.git?a=blob_plain;f=README.MinGW;hb=master). Also, Mercurial (mentioned as another alternative to git on this thread) is python-based so it should run on just about any platform. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
James Mansion wrote: Gonzalo Garramuño wrote: In summary, once you use git, if you are like me, you'll realize that you've been doing source version control wrong all these years *sigh*. Does git work on Win32? Yes, but not as well as on Linux. There's two ports of it. The cygwin port which should be more or less in sync with Linux but works very slow. It is also probably not that well suited for windows projects, as I believe no CR/LF conversion is done. The MinGW port which is much faster and already pretty functional (look for msysgit, IIRC). It also handles CR/LF conversions. This is likely the one you want to try. Some advanced functionality may still be missing as it is not a complete project yet. -- Gonzalo Garramuño [EMAIL PROTECTED] AMD4400 - ASUS48N-E GeForce7300GT Xubuntu Gutsy ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] OpenSceneGraph Find Modules
As a user of the FindOSG.cmake that's now included with OpenSceneGraph
(thanks, Eric!), I'd like to add my $0.02 and say that having multiple
FindXXX modules may be less useful in practice than it sounds in theory.
In fact, I'm already side-stepping some of the flexibility of the
existing finder, which sets the following variables:
OSG_LIBRARY -- osg
OSGUTIL_LIBRARY -- osgUtil
OSGDB_LIBRARY -- osgDB
OSGTEXT_LIBRARY -- osgText
OSGTERRAIN_LIBRARY -- osgTerrain
OSGFX_LIBRARY -- osgFX
OSGVIEWER_LIBRARY -- osgViewer
The problem I have with this is: unless you're an OSG ninja, all these
libs are always in the same dir---even the optional ones. You have to
go out of your way to set things up differently, since that's what the
CMake-ified build of OSG does. (Which is A Really Good Thing that has
made my life much, much easier. Thanks again for setting this up!!!)
With the current finder setup, if even a single one of the above
variables is NOT-FOUND, then, in practice, they're all going to be
NOT-FOUND. And you have to go clicking and clacking around in the
ccmake/cmakesetup GUI to set them all. I got a lot of negative feedback
from colleagues about this along the lines of: I thought CMake was
supposed to make this *so easy*, Wolfe! What gives?
To address their complaints, I (ab)use FindOSG.cmake in the following
way:
1. I copy it into a CMakeModules folder in my project source.
2. I modify one line in it so it also looks for the libraries in
$ENV{OSG_ROOT}/Build/bin. (The OSG build process puts libs in
${CMAKE_BINARY_DIR}/bin, and it's our convention that
CMAKE_BINARY_DIR be a folder called 'Build' under the OSG root
folder.)
3. I get the PATH component of OSG_LIBRARY using
GET_FILENAME_COMPONENT, and use that path in a LINK_DIRECTORIES
directive.
4. I only specify the basename of the libs (e.g., 'osg', 'osgDB',
'osgViewer', etc.) in TARGET_LINK_LIBRARIES, appending a 'd'
[if(WIN32)] for debug builds.
What this buys us is: a developer can instantly re-base the version of
OSG he's using by simply setting the env var OSG_ROOT from, say,
'c:/opt/OpenSceneGraph-2.2.0' to 'c:/projects/OSG-svn-trunk'. We used
to do this with ad hoc python scripts that did regex magic on the vcproj
files, which was ugly and super brittle. Now it's really simple, so
people are much more inclined to check whether a bug they find also
exists in the OSG trunk.
I realize that this usage is maybe too simplistic for some projects, but
I think/hope it can be accomodated alongside a more flexible set of
scripts with extra knobs and sliders (which we just could ignore). In
particular, I'd really appreciate having the finder do the following:
- Look for OSG_LIBRARY under $ENV{OSG_ROOT}/Build in addition to the
other places it currently looks
- Set OSG_LIBRARY_DIR to the path component of OSG_LIBRARY
For us, locating osg.lib is all that's needed to locate most all of the
'satellite' OSG libs. I can't imagine we're the only ones(?)
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
