Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Apr 2, 2008, at 4:50 PM, Bill Hoffman wrote: Nicolas Desprès wrote: On Wed, Apr 2, 2008 at 10:25 PM, Bill Hoffman [EMAIL PROTECTED] wrote: [...] I suppose we could. I like the installer as it prompts the user for the license, and setting up the command line stuff. Also, I have something working automatically with cpack. I have installed Firefox recently and the license popup when the dmg is opened. Then, you only have to drag and drop the icon in the finder to your Applications directory. I would love that DMG cpack generator could do that. Sounds neat, anyone up for creating a cpack patch? :) You can put it in the bug tracker as a feature request, but I can't promise anything quick unless there is a tested patch. -Bill Here are the complete instructions: ftp://ftp.apple.com/developer/Development_Kits/SLAs_for_UDIFs_1.0.dmg And just where exactly would I start patching CPack if I wanted to give this a try? Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
I think it should be a new CPack generator that expects a single bundle in its make install tree and that makes a simple .dmg wrapper around that bundle. Instead of PackageMaker generator, maybe a new BundleDMG generator? Thx, David On Thu, Apr 3, 2008 at 8:41 AM, Mike Jackson [EMAIL PROTECTED] wrote: On Apr 2, 2008, at 4:50 PM, Bill Hoffman wrote: Nicolas Desprès wrote: On Wed, Apr 2, 2008 at 10:25 PM, Bill Hoffman [EMAIL PROTECTED] wrote: [...] I suppose we could. I like the installer as it prompts the user for the license, and setting up the command line stuff. Also, I have something working automatically with cpack. I have installed Firefox recently and the license popup when the dmg is opened. Then, you only have to drag and drop the icon in the finder to your Applications directory. I would love that DMG cpack generator could do that. Sounds neat, anyone up for creating a cpack patch? :) You can put it in the bug tracker as a feature request, but I can't promise anything quick unless there is a tested patch. -Bill Here are the complete instructions: ftp://ftp.apple.com/developer/Development_Kits/SLAs_for_UDIFs_1.0.dmg And just where exactly would I start patching CPack if I wanted to give this a try? Mike ___ 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] CMake 2.6.0 Beta ready for testing!
David Cole wrote: I think it should be a new CPack generator that expects a single bundle in its make install tree and that makes a simple .dmg wrapper around that bundle. Instead of PackageMaker generator, maybe a new BundleDMG generator? That sounds good to me. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Fri, Mar 28, 2008 at 11:44 AM, Bill Hoffman [EMAIL PROTECTED] wrote: Mike Jackson wrote: The Qt based gui looks pretty darn good. A few things though. (May be specific to OS X). The name of the app is cmake-gui.app. Really? How about CMakeSetup.app or CMake.app (There may be name collisions with the latter.. ) We decided the name of the gui would be cmake-gui. That is what it will be called on linux and windows systems. IMHO, the best way to do this would be to have the app be CMake.app (installed directly in /Applications), then create a symlink called cmake-gui that can used from the command line. - Doug ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Doug Gregor wrote: IMHO, the best way to do this would be to have the app be CMake.app (installed directly in /Applications), then create a symlink called cmake-gui that can used from the command line. I still like having a version numbered folder for CMake. It would be: /Applications/CMake 2.6.0/CMake.app /Applications/CMake 2.6.1/CMake.app Then when the command line tools are created it would create the symlink to cmake-gui. Of course the symlinks would only be able to have one of the installed tools in a directory like /usr/local/bin. I checked and this is not uncommon with commercial software. For example, quicken uses this strategy (/Applications/Quicken 5.x/Quicken.app). I will try and get to this at some time before 2.6.0 is finalized. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Wed, Apr 2, 2008 at 9:12 AM, Bill Hoffman [EMAIL PROTECTED] wrote: Doug Gregor wrote: IMHO, the best way to do this would be to have the app be CMake.app (installed directly in /Applications), then create a symlink called cmake-gui that can used from the command line. I still like having a version numbered folder for CMake. It would be: /Applications/CMake 2.6.0/CMake.app /Applications/CMake 2.6.1/CMake.app Then when the command line tools are created it would create the symlink to cmake-gui. Of course the symlinks would only be able to have one of the installed tools in a directory like /usr/local/bin. I checked and this is not uncommon with commercial software. For example, quicken uses this strategy (/Applications/Quicken 5.x/Quicken.app). I will try and get to this at some time before 2.6.0 is finalized. -Bill That sounds great!. I think we have found that perfect balance between everybody's needs and wants. -- Mike Jackson imikejackson _at_ gee-mail dot com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Wed, Apr 2, 2008 at 9:12 AM, Bill Hoffman [EMAIL PROTECTED] wrote: Doug Gregor wrote: IMHO, the best way to do this would be to have the app be CMake.app (installed directly in /Applications), then create a symlink called cmake-gui that can used from the command line. I still like having a version numbered folder for CMake. It would be: /Applications/CMake 2.6.0/CMake.app /Applications/CMake 2.6.1/CMake.app Then when the command line tools are created it would create the symlink to cmake-gui. Of course the symlinks would only be able to have one of the installed tools in a directory like /usr/local/bin. I checked and this is not uncommon with commercial software. For example, quicken uses this strategy (/Applications/Quicken 5.x/Quicken.app). I will try and get to this at some time before 2.6.0 is finalized. That would be perfect. Thank you! - Doug ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Bill Hoffman wrote: Doug Gregor wrote: IMHO, the best way to do this would be to have the app be CMake.app (installed directly in /Applications), then create a symlink called cmake-gui that can used from the command line. I still like having a version numbered folder for CMake. It would be: /Applications/CMake 2.6.0/CMake.app /Applications/CMake 2.6.1/CMake.app I don't want to beat a horse that's already down for the count, but I'm curious why having an executable with the version number in its name (e.g., /Applications/CMake 2.6.app ) is a bad idea; having folders in /Applications is un-Mac-like, especially when there will only be a single thing inside the folder. Furthermore, if an application bundle is set up properly, it will still work should the user rename the folder -- for instance changing /Applications/CMake.app to /Applications/CMake-old.app should be OK. If CMake supports renaming the application bundle then you could even distribute it as /Applications/CMake.app and let users rename if they want multiple installed versions. Is CMake just not there yet? David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
David C Thompson wrote: I still like having a version numbered folder for CMake. It would be: /Applications/CMake 2.6.0/CMake.app /Applications/CMake 2.6.1/CMake.app I don't want to beat a horse that's already down for the count, but I'm curious why having an executable with the version number in its name (e.g., /Applications/CMake 2.6.app ) is a bad idea; having folders in /Applications is un-Mac-like, especially when there will only be a But, I do see commercial applications like quicken using the same strategy. single thing inside the folder. Furthermore, if an application bundle is set up properly, it will still work should the user rename the folder -- for instance changing /Applications/CMake.app to /Applications/CMake-old.app should be OK. If CMake supports renaming the application bundle then you could even distribute it as /Applications/CMake.app and let users rename if they want multiple installed versions. Is CMake just not there yet? If you rename it, then the symlinks for the command line will be no good anymore, other than that it works just fine with a rename. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Wed, Apr 2, 2008 at 2:48 PM, Bill Hoffman [EMAIL PROTECTED] wrote: David C Thompson wrote: I still like having a version numbered folder for CMake. It would be: /Applications/CMake 2.6.0/CMake.app /Applications/CMake 2.6.1/CMake.app I don't want to beat a horse that's already down for the count, but I'm curious why having an executable with the version number in its name (e.g., /Applications/CMake 2.6.app ) is a bad idea; having folders in /Applications is un-Mac-like, especially when there will only be a But, I do see commercial applications like quicken using the same strategy. single thing inside the folder. Furthermore, if an application bundle is set up properly, it will still work should the user rename the folder -- for instance changing /Applications/CMake.app to /Applications/CMake-old.app should be OK. If CMake supports renaming the application bundle then you could even distribute it as /Applications/CMake.app and let users rename if they want multiple installed versions. Is CMake just not there yet? If you rename it, then the symlinks for the command line will be no good anymore, other than that it works just fine with a rename. -Bill Bill, Not having looked at the new CMake.app, if I do rename the .app bundle, is there a command in the CMake.app where I can re-establish the symlinks? If not, there probably should be. Both BBEdit and TextMate have this as a command under the Help menus. They also allow the choice of a few different locations such as /usr/local/bin or /usr/bin. I have seen lots of folders get created in /Applications: MS Office. Adobe Photoshop Adobe Illustrator Adobe Anything Really Applescript Missing Sync For Palm OS Roxio Toast Titanium Retrospect 6.0 Having folders in /Applications has precedence. Having version numbers in the folder name even has precedence. If everything can be contained in just the CMake.app bundle then there really isn't a need for an enclosing folder, especially if I can rename the .app and then re-establish the symlinks from within CMake.app itself. The folder didn't bother me as much as the all lower case name did. ;-) Just for an example, I have to keep both FireFox 1.5 and 2.x around, so I have folders for each inside /Applications. philosophical note Having a simple drag and drop CMake.app install is the most preferential because it looks like there isn't a need for an installer at this point as long as everything is contained in the CMake.app bundle. Just my 2 cents. -- Mike Jackson imikejackson _at_ gee-mail dot com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Mike Jackson wrote: Bill, Not having looked at the new CMake.app, if I do rename the .app bundle, is there a command in the CMake.app where I can re-establish the symlinks? If not, there probably should be. Both BBEdit and TextMate have this as a command under the Help menus. They also allow the choice of a few different locations such as /usr/local/bin or /usr/bin. I have added a menu option to install the links that can be run after the install takes place. The installer is currently just calling cmake-gui --mac-install. I have seen lots of folders get created in /Applications: MS Office. Adobe Photoshop Adobe Illustrator Adobe Anything Really Applescript Missing Sync For Palm OS Roxio Toast Titanium Retrospect 6.0 Having folders in /Applications has precedence. Having version numbers in the folder name even has precedence. If everything can be contained in just the CMake.app bundle then there really isn't a need for an enclosing folder, especially if I can rename the .app and then re-establish the symlinks from within CMake.app itself. The folder didn't bother me as much as the all lower case name did. ;-) Mac folks really are fussy... :) Just for an example, I have to keep both FireFox 1.5 and 2.x around, so I have folders for each inside /Applications. I like the folder concept, and don't see the down side that much... philosophical note Having a simple drag and drop CMake.app install is the most preferential because it looks like there isn't a need for an installer at this point as long as everything is contained in the CMake.app bundle. I suppose we could. I like the installer as it prompts the user for the license, and setting up the command line stuff. Also, I have something working automatically with cpack. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Wed, Apr 2, 2008 at 10:25 PM, Bill Hoffman [EMAIL PROTECTED] wrote: [...] I suppose we could. I like the installer as it prompts the user for the license, and setting up the command line stuff. Also, I have something working automatically with cpack. I have installed Firefox recently and the license popup when the dmg is opened. Then, you only have to drag and drop the icon in the finder to your Applications directory. I would love that DMG cpack generator could do that. -- Nicolas Desprès ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Nicolas Desprès wrote: On Wed, Apr 2, 2008 at 10:25 PM, Bill Hoffman [EMAIL PROTECTED] wrote: [...] I suppose we could. I like the installer as it prompts the user for the license, and setting up the command line stuff. Also, I have something working automatically with cpack. I have installed Firefox recently and the license popup when the dmg is opened. Then, you only have to drag and drop the icon in the finder to your Applications directory. I would love that DMG cpack generator could do that. Sounds neat, anyone up for creating a cpack patch? :) You can put it in the bug tracker as a feature request, but I can't promise anything quick unless there is a tested patch. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Bill Hoffman wrote (of having folders in the /Applications directory): But, I do see commercial applications like quicken using the same strategy. Mike Jackson wrote: I have seen lots of folders get created in /Applications: ... Apple's guidelines ( http://developer.apple.com/documentation/MacOSX/Conceptual/BPFileSystem/Articles/WhereToPutFiles.html ) don't explicitly say not to ever create subfolders in /Applications but the only instances I know of where Apple creates them are Applescript, Utilities, and iWork -- where multiple bundles are in the subfolder. All of the other applications Mike listed either put things in those folders that Apple recommends against (e.g., readme files, etc.) or had multiple bundles in the folder. I'm just asking why there should be a folder with a single entry inside: /Applications/CMake 2.6.0/CMake.app instead of a bundle with a version number: /Applications/CMake 2.6.app or a bundle (like /Applications/CMake.app) that can be renamed to include a version number if users want to install multiple copies. If you rename it, then the symlinks for the command line will be no good anymore, other than that it works just fine with a rename. Cool! I remember seeing traffic about the various linker issues involved, but didn't know CMake had made it this far. David ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Apr 2, 2008, at 4:50 PM, Bill Hoffman wrote: Nicolas Desprès wrote: On Wed, Apr 2, 2008 at 10:25 PM, Bill Hoffman [EMAIL PROTECTED] wrote: [...] I suppose we could. I like the installer as it prompts the user for the license, and setting up the command line stuff. Also, I have something working automatically with cpack. I have installed Firefox recently and the license popup when the dmg is opened. Then, you only have to drag and drop the icon in the finder to your Applications directory. I would love that DMG cpack generator could do that. Sounds neat, anyone up for creating a cpack patch? :) You can put it in the bug tracker as a feature request, but I can't promise anything quick unless there is a tested patch. -Bill Here is how FireFox does it: http://lxr.mozilla.org/seamonkey/source/build/package/mac_osx/pkg-dmg Mike ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
David C Thompson wrote: If you rename it, then the symlinks for the command line will be no good anymore, other than that it works just fine with a rename. Cool! I remember seeing traffic about the various linker issues involved, but didn't know CMake had made it this far. So, if you don't like the version folder, you can just move it by hand, then run the setup links if you want command line tools in a specific place. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
I'd like to reiterate my request for the attached patch. CMake 2.6.0
has become even more picky about the choice of compiler and now
completely delete the cache during a make rebuild_cache stage.
Step to reproduce:
- debian oldstable (where all package are build gcc 3.3, aliased to c++)
- default c++ executable pointing to g++-4.2
When importing any of the official debian package (build with
configuration CXX=c++, which at the time was aliased to g++-3.3),
there is no way to actually say use g++-3.3 to link against the
imported package. CMake will always force to use 'c++' which is wrong.
Patch is totally non-intrusive.
Thanks
-Mathieu
Ps: of course on debian, c++ can be re-alias to anything you want, but
require root/sudo power.
On Thu, Mar 27, 2008 at 7:26 PM, Bill Hoffman [EMAIL PROTECTED] wrote:
I am happy to announce that CMake 2.6.0 has entered the beta stage! You
can find the source and binaries here: http://www.cmake.org/files/v2.6/.
I am sure I am leaving something out, but here is the list of changes
that I came up with. (If you notice something missing please let me
know and I will add it to the official release when 2.6.0 is finalized.)
Changes in CMake 2.6.0
- Documentation for all variables
- Direct CDash submit support
- Bullseye coverage support
- Use full paths for linking to libraries on all platforms. No longer
separate into -L and -l.
- Enhance the install command
- export command and ability to have imported targets
- CPack support for rpm and deb
- Cross compile support
- Introduction of the cmake_policy command
- Much better Fortran support
- Lots of bug fixes ( and most likely a few new bugs... :) )
Please try this version of CMake on your projects and report any issues
to the list or the bug tracker ( I have added a CMake-2-6 version ).
The biggest change by far is the new new cmake policies. For more
information about policies see http://www.cmake.org/Wiki/CMake_Policies.
Happy, building!
-Bill
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
--
Mathieu
Index: CMakeImportBuildSettings.cmake
===
RCS file: /cvsroot/CMake/CMake/Modules/CMakeImportBuildSettings.cmake,v
retrieving revision 1.8
diff -u -r1.8 CMakeImportBuildSettings.cmake
--- CMakeImportBuildSettings.cmake 24 Jul 2006 20:58:05 - 1.8
+++ CMakeImportBuildSettings.cmake 28 Mar 2008 10:12:30 -
@@ -119,7 +119,7 @@
ENDIF(WIN32)
# Enforce the C++ compiler setting.
-IF(CMAKE_CXX_COMPILER_MISMATCH)
+IF(CMAKE_CXX_COMPILER_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
MESSAGE(Warning: CMake is forcing CMAKE_CXX_COMPILER to
\${CMAKE_BUILD_SETTING_CXX_COMPILER}\ to match that imported
from ${CMAKE_BUILD_SETTING_PROJECT_NAME}. This is required
@@ -129,10 +129,10 @@
re-build one of those projects. Was set to ${CMAKE_CXX_COMPILER})
SET(CMAKE_CXX_COMPILER ${CMAKE_BUILD_SETTING_CXX_COMPILER}
CACHE STRING C++ compiler imported from ${CMAKE_BUILD_SETTING_PROJECT_NAME}. FORCE)
-ENDIF(CMAKE_CXX_COMPILER_MISMATCH)
+ENDIF(CMAKE_CXX_COMPILER_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
# Enforce the build type.
-IF(CMAKE_BUILD_TYPE_MISMATCH)
+IF(CMAKE_BUILD_TYPE_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
MESSAGE(Warning: CMake is forcing CMAKE_BUILD_TYPE to
\${CMAKE_BUILD_SETTING_BUILD_TYPE}\ to match that imported
from ${CMAKE_BUILD_SETTING_PROJECT_NAME}. This is required
@@ -142,11 +142,11 @@
re-build one of those projects.)
SET(CMAKE_BUILD_TYPE ${CMAKE_BUILD_SETTING_BUILD_TYPE}
CACHE STRING Build type imported from ${CMAKE_BUILD_SETTING_PROJECT_NAME}. FORCE)
-ENDIF(CMAKE_BUILD_TYPE_MISMATCH)
+ENDIF(CMAKE_BUILD_TYPE_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
# Enforce the C build variation flags.
-IF(CMAKE_C_FLAGS_DEBUG_MISMATCH)
+IF(CMAKE_C_FLAGS_DEBUG_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
MESSAGE(Warning: CMake is forcing CMAKE_C_FLAGS_DEBUG to
\${CMAKE_BUILD_SETTING_C_FLAGS_DEBUG}\ to match that imported
from ${CMAKE_BUILD_SETTING_PROJECT_NAME}.
@@ -155,9 +155,9 @@
re-build one of those projects.)
SET(CMAKE_C_FLAGS_DEBUG ${CMAKE_BUILD_SETTING_C_FLAGS_DEBUG}
CACHE STRING C DEBUG flags imported from ${CMAKE_BUILD_SETTING_PROJECT_NAME}. FORCE)
-ENDIF(CMAKE_C_FLAGS_DEBUG_MISMATCH)
+ENDIF(CMAKE_C_FLAGS_DEBUG_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
-IF(CMAKE_C_FLAGS_RELEASE_MISMATCH)
+IF(CMAKE_C_FLAGS_RELEASE_MISMATCH AND NOT CMAKE_OVERRIDE_COMPILER_MISMATCH)
MESSAGE(Warning: CMake is forcing CMAKE_C_FLAGS_RELEASE to
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Thu, Mar 27, 2008 at 7:26 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I am happy to announce that CMake 2.6.0 has entered the beta stage! You can find the source and binaries here: http://www.cmake.org/files/v2.6/. I am sure I am leaving something out, but here is the list of changes that I came up with. (If you notice something missing please let me know and I will add it to the official release when 2.6.0 is finalized.) Changes in CMake 2.6.0 - Documentation for all variables - Direct CDash submit support - Bullseye coverage support - Use full paths for linking to libraries on all platforms. No longer separate into -L and -l. - Enhance the install command - export command and ability to have imported targets - CPack support for rpm and deb - Cross compile support - Introduction of the cmake_policy command - Much better Fortran support - Lots of bug fixes ( and most likely a few new bugs... :) ) Please try this version of CMake on your projects and report any issues to the list or the bug tracker ( I have added a CMake-2-6 version ). The biggest change by far is the new new cmake policies. For more information about policies see http://www.cmake.org/Wiki/CMake_Policies. And one last thing, on Linux x86_64 can I use the Linux-i386 cmake ? There seems to be an issue with load_command: Running CMake to regenerate build system... -- Loading VTK CMake commands CMake Error at /usr/local/lib/vtk/CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND): load_command Attempt to load the library /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so failed. Additional error info is: /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so: cannot open shared object file: No such file or directory Call Stack (most recent call first): /usr/local/lib/vtk/CMake/vtkLoadCMakeExtensions.cmake:17 (VTK_LOAD_SINGLE_CMAKE_EXTENSION) /usr/local/lib/vtk/UseVTK.cmake:28 (VTK_LOAD_CMAKE_EXTENSIONS) Utilities/VTK/CMakeLists.txt:21 (INCLUDE) CMake Error: Loading VTK command VTK_WRAP_TCL2 - failed -- Configuring done make: *** [rebuild_cache] Error 1 [EMAIL PROTECTED]:/src/src-uptodate-x64-gdcm2/branches/release-gcc$ ls -al /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so -rw-r--r-- 1 root staff 18893 2007-07-04 11:34 /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so I'll recompile cmake 2.6.0 and check if recompilation fix the issue. thanks, -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Thu, Mar 27, 2008 at 7:26 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I am happy to announce that CMake 2.6.0 has entered the beta stage! You can find the source and binaries here: http://www.cmake.org/files/v2.6/. I am sure I am leaving something out, but here is the list of changes that I came up with. (If you notice something missing please let me know and I will add it to the official release when 2.6.0 is finalized.) Changes in CMake 2.6.0 - Documentation for all variables - Direct CDash submit support - Bullseye coverage support - Use full paths for linking to libraries on all platforms. No longer separate into -L and -l. - Enhance the install command - export command and ability to have imported targets - CPack support for rpm and deb - Cross compile support - Introduction of the cmake_policy command - Much better Fortran support - Lots of bug fixes ( and most likely a few new bugs... :) ) Please try this version of CMake on your projects and report any issues to the list or the bug tracker ( I have added a CMake-2-6 version ). The biggest change by far is the new new cmake policies. For more information about policies see http://www.cmake.org/Wiki/CMake_Policies. What happen to the ccmake executable (ncurses app) ? Thanks, -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Fri, Mar 28, 2008 at 11:53 AM, Mathieu Malaterre [EMAIL PROTECTED] wrote: And one last thing, on Linux x86_64 can I use the Linux-i386 cmake ? There seems to be an issue with load_command: Running CMake to regenerate build system... -- Loading VTK CMake commands CMake Error at /usr/local/lib/vtk/CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND): load_command Attempt to load the library /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so failed. Additional error info is: /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so: cannot open shared object file: No such file or directory Call Stack (most recent call first): /usr/local/lib/vtk/CMake/vtkLoadCMakeExtensions.cmake:17 (VTK_LOAD_SINGLE_CMAKE_EXTENSION) /usr/local/lib/vtk/UseVTK.cmake:28 (VTK_LOAD_CMAKE_EXTENSIONS) Utilities/VTK/CMakeLists.txt:21 (INCLUDE) CMake Error: Loading VTK command VTK_WRAP_TCL2 - failed -- Configuring done make: *** [rebuild_cache] Error 1 [EMAIL PROTECTED]:/src/src-uptodate-x64-gdcm2/branches/release-gcc$ ls -al /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so -rw-r--r-- 1 root staff 18893 2007-07-04 11:34 /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so I'll recompile cmake 2.6.0 and check if recompilation fix the issue. Setting CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4 did the trick. Thanks, -- Mathieu ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
2008/3/28, Mathieu Malaterre [EMAIL PROTECTED]: I'll recompile cmake 2.6.0 and check if recompilation fix the issue. Setting CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4 did the trick. Shouldn't you use CMAKE_POLICY instead of CMAKE_BACKWARDS_COMPATIBILITY http://www.cmake.org/Wiki/CMake_Policies As far as I understand it should be something like: cmake_minimum_required(VERSION 2.4) if(COMMAND cmake_policy) # policy settings ... cmake_policy(VERSION 2.4) endif(COMMAND cmake_policy) I've recently discovered CMake policy so my advise may be 'blind' :=) -- Erk ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Mathieu Malaterre wrote: And one last thing, on Linux x86_64 can I use the Linux-i386 cmake ? There seems to be an issue with load_command: Running CMake to regenerate build system... -- Loading VTK CMake commands CMake Error at /usr/local/lib/vtk/CMake/vtkLoadCMakeExtensions.cmake:7 (LOAD_COMMAND): load_command Attempt to load the library /usr/local/lib/vtk/CMake/libcmVTK_WRAP_TCL2.so failed. Additional error info is: This is not a new issue. The type of cmake must match the build tools being used if loaded command is used. BTW, newer versions of VTK should not have any loaded commands in it. (for this reason). So you have to use 64 bit cmake with a 64 bit build for any project that uses loaded commands. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Mathieu Malaterre wrote: What happen to the ccmake executable (ncurses app) ? I am working on a fix for this. It will be in the next RC. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
I tried the OSX Universal dmg and the install process appears to have gone badly. I already have cmake 2.4.8 installed so that appears to have caused at least some issues. The 2.6 installer asked me where I wanted it to put the command-line links and I used the default /usr/bin/. The first time, it appeared to do nothing because when I ran cmake --version it said something like 2.4 patch 8 (I don't remember exactly, but not 2.6). I manually removed the cmake files from /usr/bin/ and reran the installer. Now it appears to have recreated the files, but when I run cmake --version (or cmake --help) I get this: $ cmake --version CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in /usr/bin Bus error Any ideas? Is there a problem with my cmake 2.4.8 conflicting? How do I remove 2.4.8 and my messed up 2.6 so I can try again? Also, while I only recently switched to a Mac, it does not appear to be common that you create a subdirectory in Applications by default. It seems like it would be nice if the cmake-gui application bundle was just directly in Applications. That isn't a big deal, just a thought. David Thulson On Thu, Mar 27, 2008 at 1:26 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I am happy to announce that CMake 2.6.0 has entered the beta stage! You can find the source and binaries here: http://www.cmake.org/files/v2.6/. I am sure I am leaving something out, but here is the list of changes that I came up with. (If you notice something missing please let me know and I will add it to the official release when 2.6.0 is finalized.) Changes in CMake 2.6.0 - Documentation for all variables - Direct CDash submit support - Bullseye coverage support - Use full paths for linking to libraries on all platforms. No longer separate into -L and -l. - Enhance the install command - export command and ability to have imported targets - CPack support for rpm and deb - Cross compile support - Introduction of the cmake_policy command - Much better Fortran support - Lots of bug fixes ( and most likely a few new bugs... :) ) Please try this version of CMake on your projects and report any issues to the list or the bug tracker ( I have added a CMake-2-6 version ). The biggest change by far is the new new cmake policies. For more information about policies see http://www.cmake.org/Wiki/CMake_Policies. Happy, building! -Bill ___ 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] CMake 2.6.0 Beta ready for testing!
David Thulson wrote: I tried the OSX Universal dmg and the install process appears to have gone badly. I already have cmake 2.4.8 installed so that appears to have caused at least some issues. The 2.6 installer asked me where I wanted it to put the command-line links and I used the default /usr/bin/. The first time, it appeared to do nothing because when I ran cmake --version it said something like 2.4 patch 8 (I don't remember exactly, but not 2.6). I manually removed the cmake files from /usr/bin/ and reran the installer. Now it appears to have recreated the files, but when I run cmake --version (or cmake --help) I get this: $ cmake --version CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in /usr/bin Bus error Any ideas? Is there a problem with my cmake 2.4.8 conflicting? How do I remove 2.4.8 and my messed up 2.6 so I can try again? Sadly the mac does not have uninstall... You should be able to remove all the stuff in /usr/bin /usr/share cmake related. Also, while I only recently switched to a Mac, it does not appear to be common that you create a subdirectory in Applications by default. It seems like it would be nice if the cmake-gui application bundle was just directly in Applications. That isn't a big deal, just a thought. Can you try: http://www.cmake.org/files/vCVS/cmake-2.7.20080327-Darwin-universal.dmg That should fix the segfault. It should also install well on top of the other stuff you have. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Actually, creating subfolders in /Applications has lots of precedence. Larger applications will do this type of action because there are so many support files. Look at Adobe Photoshop, iWork, MSOffice and lots of others. If a developer has more than just an App bundle then they really should be making their own subdirectory in /Applications. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Mar 28, 2008, at 10:27 AM, David Thulson wrote: Also, while I only recently switched to a Mac, it does not appear to be common that you create a subdirectory in Applications by default. It seems like it would be nice if the cmake-gui application bundle was just directly in Applications. That isn't a big deal, just a thought. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Mike Jackson wrote: The Qt based gui looks pretty darn good. A few things though. (May be specific to OS X). The name of the app is cmake-gui.app. Really? How about CMakeSetup.app or CMake.app (There may be name collisions with the latter.. ) We decided the name of the gui would be cmake-gui. That is what it will be called on linux and windows systems. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
It does not appear that CMake 2.6.0 puts anything but the cmake-gui.app bundle in the /Applications subdirectory. I suppose that having separate dirs is nice for beta releases, but does it really make sense for the default? David Thulson On Fri, Mar 28, 2008 at 9:54 AM, Mike Jackson [EMAIL PROTECTED] wrote: Actually, creating subfolders in /Applications has lots of precedence. Larger applications will do this type of action because there are so many support files. Look at Adobe Photoshop, iWork, MSOffice and lots of others. If a developer has more than just an App bundle then they really should be making their own subdirectory in /Applications. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Mar 28, 2008, at 10:27 AM, David Thulson wrote: Also, while I only recently switched to a Mac, it does not appear to be common that you create a subdirectory in Applications by default. It seems like it would be nice if the cmake-gui application bundle was just directly in Applications. That isn't a big deal, just a thought. ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
No change with the nightly build. Here is what I did: Macintosh-10:bin davidthulson$ which cmake /usr/bin/cmake Macintosh-10:bin davidthulson$ ls -l /usr/bin/cmake lrwxr-xr-x 1 root wheel 65 Mar 28 11:02 /usr/bin/cmake - /Applications/CMake 2.7-20080327/cmake-gui.app/Contents/bin/cmake Macintosh-10:bin davidthulson$ cmake CMake Error: Could not find CMAKE_ROOT !!! CMake has most likely not been installed correctly. Modules directory not found in /usr/bin Bus error Macintosh-10:bin davidthulson$ Ideas? Should the install be setting an environment variable? Let me know what else I can try, thanks. David Thulson On Fri, Mar 28, 2008 at 9:35 AM, Bill Hoffman [EMAIL PROTECTED] wrote: Can you try: http://www.cmake.org/files/vCVS/cmake-2.7.20080327-Darwin-universal.dmg That should fix the segfault. It should also install well on top of the other stuff you have. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Eric Noulard wrote: 2008/3/28, Mathieu Malaterre [EMAIL PROTECTED]: I'll recompile cmake 2.6.0 and check if recompilation fix the issue. Setting CMAKE_BACKWARDS_COMPATIBILITY:STRING=2.4 did the trick. Shouldn't you use CMAKE_POLICY instead of CMAKE_BACKWARDS_COMPATIBILITY http://www.cmake.org/Wiki/CMake_Policies As far as I understand it should be something like: cmake_minimum_required(VERSION 2.4) if(COMMAND cmake_policy) # policy settings ... cmake_policy(VERSION 2.4) endif(COMMAND cmake_policy) I've recently discovered CMake policy so my advise may be 'blind' :=) Look at the documentation of cmake_minimum_required. It will implicitly call cmake_policy(VERSION). See documentation of policy CMP0001 for how compatibility with CMake 2.4 and below works. Anyway, Mathieu's problem was about trying to load 32-bit and 64-bit code in the same process. -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Mathieu Malaterre wrote: I'd like to reiterate my request for the attached patch. CMake 2.6.0 has become even more picky about the choice of compiler and now completely delete the cache during a make rebuild_cache stage. Step to reproduce: - debian oldstable (where all package are build gcc 3.3, aliased to c++) - default c++ executable pointing to g++-4.2 When importing any of the official debian package (build with configuration CXX=c++, which at the time was aliased to g++-3.3), there is no way to actually say use g++-3.3 to link against the imported package. CMake will always force to use 'c++' which is wrong. Patch is totally non-intrusive. Applied. Did you ever add this to the bug tracker? -Brad ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Brad King wrote: It looks like no one built with --system-libs since that CHECK_INCLUDE_FILE line was added. Try adding the line INCLUDE(CheckIncludeFile) at the top of the file. I've already committed this to CMake CVS. Please let me know if there are more problems. That took care of that, thanks. No other problems so far. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane [EMAIL PROTECTED] Boulder, CO 80301 http://www.cora.nwra.com ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
On Thu, Mar 27, 2008 at 2:26 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I am happy to announce that CMake 2.6.0 has entered the beta stage! You can find the source and binaries here: http://www.cmake.org/files/v2.6/. When I try to download the self-extracting script (cmake-2.6.0-RC-5-Linux-i386.sh) I get an error from the web server: Sorry, error 500 malformed header from script. Bad header=This is a self-extracting arch: cmake-2.6.0-RC-5-Linux-i386.sh I can get a different installation package, but just be warned that that particular installer isn't getting tested. - Doug ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Doug Gregor wrote: On Thu, Mar 27, 2008 at 2:26 PM, Bill Hoffman [EMAIL PROTECTED] wrote: I am happy to announce that CMake 2.6.0 has entered the beta stage! You can find the source and binaries here: http://www.cmake.org/files/v2.6/. When I try to download the self-extracting script (cmake-2.6.0-RC-5-Linux-i386.sh) I get an error from the web server: Sorry, error 500 malformed header from script. Bad header=This is a self-extracting arch: cmake-2.6.0-RC-5-Linux-i386.sh I can get a different installation package, but just be warned that that particular installer isn't getting tested. Thanks, should be fixed now. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
That did much better, although it still won't overwrite existing /usr/bin links. I have to go in and manually delete them. I think since the user explicitly requests that the links be added to /usr/bin/, it should either overwrite existing links without warning or ask the user for confirmation. It seems like doing nothing will result in a lot of people thinking the install failed when they try to type cmake on the command line and still get cmake 2.4. I'll look into it more tomorrow when I have more time. Thanks for the help. David Thulson On Fri, Mar 28, 2008 at 2:54 PM, Bill Hoffman [EMAIL PROTECTED] wrote: David Thulson wrote: No change with the nightly build. Here is what I did: OK, this time I tested it... :) This one should work: http://www.cmake.org/files/vCVS/cmake-2.7.20080328-Darwin-universal.dmg -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake 2.6.0 Beta ready for testing!
Hi! On Thu, Mar 27, 2008 at 02:26:02PM -0400, Bill Hoffman wrote: I am happy to announce that CMake 2.6.0 has entered the beta stage! You can find the source and binaries here: http://www.cmake.org/files/v2.6/. I must be doing something terribly wrong here, but files in http://www.cmake.org/files/v2.6/ are using DOS newlines, which breaks things under Linux. I converted a lot of them to the Unix convention and CMake built correctly and worked fine for my projects. What is the right way of building this version under Linux? Thank you for CMake! -- Adiel Mittmann ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
