Re: [CMake] CMake, Qt4, Ubuntu and Phonon
Clinton, I did a small test and it works with qmake because phonon is the standard search paths. It justs add -lphonon to the compiler command line. If not patched, there should be a note in the CMake FindQt4 documentation about the fact that it doesn't support finding phonon as a 3rd party module (as opposed to a standard Qt4 module). I agree with your concern about different Qt version and Phonon. On Ubuntu, it seems ok to do so because they control the package released, but the behavior might become undefined if someone decides to build their own version using incompatible Qt/Phonon combination. That could also be mentioned in the module documentation, if patched. It would also be possible to detect if the phonon found by the CMake module is part of the Qt4 release by comparing its location with the library path returned by qmake? Do you see any potential issue with that approach? Regards, -- Félix C. Morency, M.Sc. Plateforme d’analyse et de visualisation d’images Centre Hospitalier Universitaire de Sherbrooke Centre de recherche clinique Étienne-Le Bel Local Z5-3031 | 819.346.1110 ext 16634 On Tue, Nov 22, 2011 at 5:11 PM, Clinton Stimpson clin...@elemtech.com wrote: On Tuesday, November 22, 2011 02:34:55 pm Félix C. Morency wrote: As we pointed out in the bug thread located at https://bugs.launchpad.net/ubuntu/+source/phonon/+bug/893170 the FindPhonon script is not portable to Windows. I agree with André's comment: the source of the problem is the Ubuntu way of distributing Qt4 and Phonon. We also have to keep in mind that the official CMake module FindQt4 doesn't actually find Qt4 correctly on Ubuntu. I think this is a problem for both Ubuntu and CMake. The two solutions to this problem I can think of are 1) Patch the FindQt4 script so it can find Phonon correctly when not distributed with Qt4 and 2) Make pressure on the Ubuntu community so it distribute Phonon as a Qt4 (optional) package (like Debian does). I would like to have your feedback on this issue so we can discuss alternative solutions. Feel free to comment on the bug report to make pressure on the Ubuntu community. I would be happy to patch the FindQt4 module if the community agrees on this solution. Does it work if one is using qmake simply because phonon is in the linker's standard search paths? Or does qmake on Ubuntu know how to find phonon? phonon is treated as a Qt module as far as qmake and FindQt4.cmake are concerned, and not as a 3rd party library, like zlib and others. But, I'm not opposed to modifying FindQt4.cmake, but I have a concern if one builds their own Qt (different version) without phonon, is it OK to find /usr/lib/libphonon.so? -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake, Qt4, Ubuntu and Phonon
As we pointed out in the bug thread located at https://bugs.launchpad.net/ubuntu/+source/phonon/+bug/893170 the FindPhonon script is not portable to Windows. I agree with André's comment: the source of the problem is the Ubuntu way of distributing Qt4 and Phonon. We also have to keep in mind that the official CMake module FindQt4 doesn't actually find Qt4 correctly on Ubuntu. I think this is a problem for both Ubuntu and CMake. The two solutions to this problem I can think of are 1) Patch the FindQt4 script so it can find Phonon correctly when not distributed with Qt4 and 2) Make pressure on the Ubuntu community so it distribute Phonon as a Qt4 (optional) package (like Debian does). I would like to have your feedback on this issue so we can discuss alternative solutions. Feel free to comment on the bug report to make pressure on the Ubuntu community. I would be happy to patch the FindQt4 module if the community agrees on this solution. Regards, -- Félix C. Morency, M.Sc. Plateforme d’analyse et de visualisation d’images Centre Hospitalier Universitaire de Sherbrooke Centre de recherche clinique Étienne-Le Bel Local Z5-3031 | 819.346.1110 ext 16634 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMake, Qt4, Ubuntu and Phonon
I filled a bug report on launchpad regarding the use of CMake, Qt4, Ubuntu 11.10-64 and Phonon. https://bugs.launchpad.net/ubuntu/+source/phonon/+bug/893170 The problem is that the FindQt4 module tries to find phonon in the path where the Qt4 library are located. This default path under Ubuntu 11.10-64 is QT_INSTALL_LIBS:/usr/lib/x86_64-linux-gnu Phonon is not included in the default libqt4-dev. By default, the libphonon-dev package installs the library in /usr/lib. Since the NO_DEFAULT_PATH parameter is given when looking for the Phonon library, it is never found in /usr/lib. Temporary workaround would be to look for the phonon library without using the FindQt4 module. I don't know what the proper permanent fix should be. Fix the phonon Ubuntu package so it installs at the same location as Qt4 or fix the FindQt4 module to allows looking in default paths. I would like your input on this issue and alternative permanent solution to the problem. Regards, -- Félix C. Morency, M.Sc. Plateforme d’analyse et de visualisation d’images Centre Hospitalier Universitaire de Sherbrooke Centre de recherche clinique Étienne-Le Bel Local Z5-3031 | 819.346.1110 ext 16634 -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Git support status in CMake/CTest/CDash
Hi, I want to know if there are any progress on git support for CMake/CTest/CDash. Is this planned to be released soon? Regards, Félix C. Morency ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] [PATCH] FreeBSD Lua5.x default install path
It is exactly the same paths under FreeBSD 7.0-RELEASE. I know it doesn't prove anything concerning 7.1 but it haven't changed since the beta. Cheers, Félix On Wed, Oct 22, 2008 at 3:06 PM, E. Wing [EMAIL PROTECTED] wrote: Sorry, I've been a bit buried recently and I know there are some other Lua patches pending. But I think this is reasonable to add if FreeBSD is really going to do this. I doubt the addition will break anything for other platforms. But since 7.1 is still beta, do you have it in authority that this is what FreeBSD is going to settle on? No sense adding it if they are going to change their minds. As for the duplication list, it was originally because many of these paths were not included by CMake or they were not consistent among different platforms. I think this has been fixed, but I haven't verified it so I haven't removed it in case it breaks somebody. It later got into kind of a documentation/tutorial thing where (new) people started looking at that to get a sense of understanding/comfort at what was going on, especially when their files were not found for a reason they didn't understand. Maybe it wasn't the most appropriate use of the field, but that's what happened. Thanks, Eric On 10/22/08, Alexander Neundorf [EMAIL PROTECTED] wrote: On Wednesday 22 October 2008, Félix C. Morency wrote: Hi, It appears that FreeBSD 7.1 (beta) installs Lua5.1 in the following default path: /usr/local/lib/lua51/ The current FindLua51 module doesn't search in this path and this results in a not found library. Some goes for Lua5.0. I attached two patches (one for 5.0 and one for 5.1) that add the correct path suffix for the library to be found under FreeBSD 7.1 (beta). Nice straight-forward patches. Eric, what do you think ? I had a quick look at FindLua5?.cmake and noticed that in the FIND_LIBRARY() calls all the default dirs are listed again, e.g. /usr/local, /opt, /opt/local etc. (see Modules/Platforms/UnixPaths.cmake for the full list of default search directories). Can they be removed there ? I don't feel like doing this, Eric should be better qualified for this. Alex ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] FindCurses missing stuff
Hi, The current FindCurses module doesn't support the wide char version of the libraries (cursesw/ncursesw). I would like to hear your point of view about how to add this to the current module. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] [PATCH] FindLua5x header documentation fix
Hi, This is a small fix to FindLua5x header documentation. Cheers, Félix C. Morency ? findLua5x_headerDocFix.patch Index: FindLua50.cmake === RCS file: /cvsroot/CMake/CMake/Modules/FindLua50.cmake,v retrieving revision 1.4 diff -r1.4 FindLua50.cmake 4c4 # LUA_FOUND, if false, do not try to link to Lua --- # LUA50_FOUND, if false, do not try to link to Lua Index: FindLua51.cmake === RCS file: /cvsroot/CMake/CMake/Modules/FindLua51.cmake,v retrieving revision 1.5 diff -r1.5 FindLua51.cmake 4c4 # LUA_FOUND, if false, do not try to link to Lua --- # LUA51_FOUND, if false, do not try to link to Lua ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Check if a target has been added
Thank you Alexander, the LOCATION solution worked like a charm. Cheers, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Check if a target has been added
Hi, I posted a message yesterday and found out that the method wasn't quite effective. If there any way of checking if a target has already been added to the build chain (resetting it at each configure) ? I have lots of projects depending on the same target and this produces makefile warnings and VS. annoying popups. Cheers, Félix ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CommandLine VS GUI
Hi, I'm using the cache to avoid multiple target of the same library: if( not libname_already_defined ) set( libname_already_defined TRUE CACHE INTERNAL TRUE ) ... endif( not libname_already_defined ) It works well under linux using the command line tool. The command line also produces a good solution to be used under VS. However, the GUI tool doesn't seems to behave like the command line tool. The problem is that the GUI tool performs a configure twice and the second time, the variables in the cache are already set. The results is that the outputted solution doesn't contain the libraries. Is there any workaround for the problem ? Cheers, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Potential CMake bug ?
Hi,
Here's the situation:
Install is performed according to the ${CMAKE_INSTALL_PREFIX}:
install( FILES ${someFile) DESTINATION ${someRelativePath} )
This works great and don't need admin rights to make package.
The problem is that I can't install anything in /etc without redefining the
CMAKE_INSTALL_PREFIX to / or I need admin right to make package.
This is a very ugly hack IMHO.
Any other workaround ?
Cheers,
Félix
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CodeBlocks generator issues
Philip, You seem to be right. Changing the build target to the name of my project did the trick. I can now run and debug the program successfully. Thank you, Félix C. Morency On 3/2/08, Philip Lowman [EMAIL PROTECTED] wrote: On Sun, Mar 2, 2008 at 7:06 PM, Félix C. Morency [EMAIL PROTECTED] wrote: Hi, I just discovered that CMake SVN (future 2.6.0) currently supports CodeBlocks project generation. I gave it a try and the result seems promising. I've been able to successfully compile my project under CodeBlocks 8.02. However, running the program (which is a command line program) from CodeBlocks with the Run command doesn't work. The error is: You can't run a commands-only target Another issue is the debugging tool which doesn't start with this error: The selected target is only running pre/post build step commands. Can't debug such a target I guess those issues come from CMake since all those features work with what I call a pure CodeBlocks project. Are those issues already known and if yes, are you planning on fixing them with the release of the 2.6.0version ? Félix, I don't know anything about CodeBlocks but I do know with the Visual Studio generator the default project is ALL_BUILD which you can't debug. In order to Debug with Visual Studio you have to right click on the desired target and choose Debug (or change your default project). Maybe there's a similar issue with CodeBlocks? Be sure to file a bug on this issue in the CMake bug database if you're still having problems. http://www.cmake.org/Bug/main_page.php -- Philip Lowman ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CodeBlocks generator issues
Hi, I just discovered that CMake SVN (future 2.6.0) currently supports CodeBlocks project generation. I gave it a try and the result seems promising. I've been able to successfully compile my project under CodeBlocks 8.02. However, running the program (which is a command line program) from CodeBlocks with the Run command doesn't work. The error is: You can't run a commands-only target Another issue is the debugging tool which doesn't start with this error: The selected target is only running pre/post build step commands. Can't debug such a target I guess those issues come from CMake since all those features work with what I call a pure CodeBlocks project. Are those issues already known and if yes, are you planning on fixing them with the release of the 2.6.0 version ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: Migration to subversion
And what about Bazaar (the tool used by Ubuntu/Caronical) ? http://bazaar-vcs.org/ Regards, Félix C. Morency Message: 2 Date: Sat, 22 Dec 2007 18:53:10 -0500 From: Brandon Van Every [EMAIL PROTECTED] Subject: Re: [CMake] Re: Migration to subversion To: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 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. Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Waf build tool
I took a close look to Waf some months ago while searching for the ideal build tool for the projects I had to port. I used to talk a lot with the author and found out that the Waf build system isn't superior at all to other alternatives like CMake. Also, the author just don't care about other OS than Linux (that is partly why KDE haven't made the switch to Waf). In continuation with this idea, the MSVC support is very (very) poor. Also, the author isn't very mind opened (to new ideas). And he don't like CMake ;). The author might have good ideas although but I don't like the way it is implemented. Regards, Félix C. Morency Date: Mon, 17 Dec 2007 19:38:28 -0500 From: Brandon Van Every [EMAIL PROTECTED] Subject: Re: [CMake] Waf build tool To: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Dec 16, 2007 1:11 PM, Gonzalo Garramuño [EMAIL PROTECTED] wrote: In summary, thanks. But, no thanks. With all those problems I did not even bother checking the speed. I got a chuckle out of their self-description on http://www.ohloh.net/tags/build/make , which one might view as a short list of open source build tools. Though it comes last in the arena of the build systems, we believe that Waf is a vastly superior alternative to its competitors (Autotools, Scons, Cmake, Ant, etc) for building software, and especially for open-source projects Yep, that's why it's in the top tier of Popular tools! :-) There's something to be said for tooting your own horn, but not to the extent of making oneself soft or complacent about a competitor's capabilities. I think the day that CMake has really won the build tool wars, we'll be seeing shelfs full of books at Barnes Noble and tons of jobs listing it as a must have skill. I wonder where Waf thinks it is, relative to all of that. Happy with the $0 we really don't have to bother with Windows open source market? Cheers, Brandon Van Every ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] SET_TARGET_PROPERTIES question on MacOSX
Mike, Thank again for your answers. I checked your tool and it seems to work great here. I will add some more features (QT4 sublibs) to it and send you the patch asap. I will follow your advices and concentrate my efforts on making my bundle the good way. Regards, Félix C. Morency On Dec 4, 2007 5:02 PM, Mike Jackson [EMAIL PROTECTED] wrote: On Dec 4, 2007, at 4:46 PM, Félix C. Morency wrote: Mike, Thank you for your precise answer. I will try this tomorrow. I have few other questions for you: 1.0) Why isn't CMake doing this automatically ? CMake will set the install_path for you if you use the SET_TARGET_PROPERTIES macro. This just applies to libraries that CMake builds for you. Xcode would be no different in this respect 1.1) Is is just a CMake's missing feature or is there any technical issues ? I think QMake does it for you isn't is ? See above. Qmake _might_ do it the same way cmake does, by setting a bunch of link flags. check with qmake. 2.0) I'm sure Apple has plenty of reasons for doing libs handling this way but is it only me or this is completly retard ? It is Different. Apple wants the user experience to be easy and straight forward. This also includes installing programs and applications. It should be a Drag-and-Drop process if at all possible. There are times when this is just not possible. For MOST programs out there, this is absolutely possible. Because Apple would like everything to be in a bundled app there needs to be special install_names (or rpaths) in the libraries. This is the need. 2.1) I'm not sure but I don't think linux is working this way isn't it ? No. Linux and to some extent windows do not work this way. Then again, windows has DLL Hell because all the dlls are just put in the same directory. So what happens when your installer puts version 1 of a library in /usr/local and my installer overwrites your lib with version 2? Your app stops working and a lot of finger pointing takes place. If you spend the time upfront as a developer to package your application properly you avoid having to deal with this problem. 2.2) Wouldn't it be easier just to install all the libs with CPack in standard location (/usr/lib) if possible ? See above. NEVER install ANYTHING in /usr/lib on OS X. That is reserved for APPLE supplied stuff. If you have to put it somewhere, then /usr/local/lib is better. If you have frameworks then put those in /Library/Frameworks, but you better have a REALLY good reason for putting something in there. Package the App how Apple wants and you will find that you spend less time troubleshooting problems on OS X and more time coding. You can look at my examples to see how I am doing things. You are perfectly allowed to use any of my code in your projects. If you make them better I would appreciate knowing. Libs handling under OSX is a real PITA. I will give you my feedback soon. It is a PITA when your build system does not properly/easily support them. Even in Xcode, it is tricky to get things setup correctly so cmake isn't going to be any easier. Examples help. Look at mine. They take a lot of the burden off you and should be able to Do the right thing for your libs. That being said I do NOT warranty them against bugs. If you find a bug let me know. I'll do what I can to fix them. I am compiling on OS X 10.4.11 (Intel and PPC). The scripts seem to work for my setup. Also, if you have control over how all your support libs are compiled you can always compile them as static and avoid these problems. Hope that answers your questions. Mike Jackson ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] SET_TARGET_PROPERTIES question on MacOSX
Hi, The INSTALL_NAME_DIR is a string specifying the directory portion of the install_name field of shared libraries on Mac OSX to use in the installed targets (as taken from the current documentation). Is there any way of setting this property on a third party lib ? I checked the current CVS CMake's examples (Bundle and Framework) and I couldn't find an positive answer about third party libraries (I installed mine in Content/Plugins). If not, if there any other way to include third party libs within the bundle and make the application find it ? I also installed Qt's framework within my bundle with the INSTALL( DIRECTORY...) command. Is there any better way to do this ? I think the current tools work great with CMake generated libs/projects/framework but I think there is a lack in third libs/projects/framework party inclusion support. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] SET_TARGET_PROPERTIES question on MacOSX
Mike, Thank you for your precise answer. I will try this tomorrow. I have few other questions for you: 1.0) Why isn't CMake doing this automatically ? 1.1) Is is just a CMake's missing feature or is there any technical issues ? I think QMake does it for you isn't is ? 2.0) I'm sure Apple has plenty of reasons for doing libs handling this way but is it only me or this is completly retard ? 2.1) I'm not sure but I don't think linux is working this way isn't it ? 2.2) Wouldn't it be easier just to install all the libs with CPack in standard location (/usr/lib) if possible ? Libs handling under OSX is a real PITA. I will give you my feedback soon. Regards, Félix C. Morency On Dec 4, 2007 4:08 PM, Mike Jackson [EMAIL PROTECTED] wrote: Welcome to the can of worms called install_name_tool on OS X. Yes, you can change 3rd party libs.. with one BIG caveat. Who ever compiled it needs to have compiled with the -Header_Pad_Max_install_Names (or something like that). If that was done then you should be able to change the library. Say we have a 3rd party lib Foo. Lets run otool -L libFoo.dylib and see what we get. /usr/local/lib/libFoo.dylib /usr/lib/libSystem.B.dylib So what we want to do is the following: install_name_tool -id @executable_path/../Plugins/libFoo.dylib MyApp.app /Contents/Plugins/libFoo.dylib That is the first part. Now we need to change the actual executable also. install_name_tool -change /usr/local/lib/libFoo.dylib executable_path/../Plugins/libFoo.dylib MyApp.app/Contents/MacOS/MyApp You can check things are correct by running: otool -L MyApp.app/Contents/Plugins/libFoo.dylib otool -L MyApp.app/Contents/MacOS/MyApp When you look at the output from those, the paths that refer to libFoo.dylib should all have @executable_path/../Plugins/libFoo.dylib in them. Shell scripts are great for this. I have some that I have made up just for this purpose. CMake configures them, then runs them after the build. Qt... Again.. that same thing as above BUT You have to correct each and every Qt library that you use PLUS make sure you get all the dependancies correct, ie, if your app depends on QtCore and QtGui. you have to make the following changes. Change MyApp to look for QtCore and QtGui in @executable_path/../Frameworks/QtCore.framework/QtCore Change the install_name on QtCore and QtGui to each be @executable_path/../Frameworks/[fill in the rest] Change QtGui to look for QtCore in @executable_path/../Frameworks/QtCore.framework/QtCore Sound like fun? It isn't. I submitted a bug to Trolltech to properly support this and got a reply that basically said install_name does not exist on OS X? Huh? You are welcome to look at the following locations and take what ever you want/need to get your build to work. This script does some of the above for some 3rd party libs that I use in my app http://titanium.imts.us/viewvc/Task_7/MXADataModel/Resources/PackageMXALibsForOSXAppBundle.sh.in?view=markup This script attempts to do everything for QtCore and QtGui also. http://titanium.imts.us/viewvc/Task_7/MXATools/Resources/PackageQt4ForOSXAppBundle.sh.in?view=markup Hope some of that helps. -- Mike Jackson Senior Research Engineer Innovative Management Technology Services On Dec 4, 2007, at 3:51 PM, Félix C. Morency wrote: Hi, The INSTALL_NAME_DIR is a string specifying the directory portion of the install_name field of shared libraries on Mac OSX to use in the installed targets (as taken from the current documentation). Is there any way of setting this property on a third party lib ? I checked the current CVS CMake's examples (Bundle and Framework) and I couldn't find an positive answer about third party libraries (I installed mine in Content/Plugins). If not, if there any other way to include third party libs within the bundle and make the application find it ? I also installed Qt's framework within my bundle with the INSTALL( DIRECTORY...) command. Is there any better way to do this ? I think the current tools work great with CMake generated libs/projects/framework but I think there is a lack in third libs/projects/framework party inclusion support. Regards, Félix C. Morency ___ 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] Using the WiX Generator for CPack
Message: 1 Date: Thu, 29 Nov 2007 09:09:12 -0500 From: David Cole [EMAIL PROTECTED] Subject: Re: [CMake] Using the WiX Generator for CPack To: Marcus [EMAIL PROTECTED] Cc: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 It does not yet exist. If you would like to contribute one, I would be happy to coordinate getting it into the CMake code base. If not, it may just be an idea for some time to come... Some people were talking about using the InstallJammer installer into CPack: http://www.installjammer.com/ WiX does not seem to be portable to other platform than Windows. Regards, Félix C. Morency :-) David On 11/25/07, Marcus [EMAIL PROTECTED] wrote: Hi, A CPack WiX Generator is mentioned on this page in the wiki: http://www.cmake.org/Wiki/CPack:Generator_Information Does this generator actually exist? I can't find any other information about it. Thanks, Marcus ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake -- next part -- An HTML attachment was scrubbed... URL: http://public.kitware.com/pipermail/cmake/attachments/20071129/bcf35c6f/attachment.html -- ___ 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] Re: CMake Digest, Vol 43, Issue 105
Hendrik, I know that the current generators aren't portable. What I'm talking about is I think it would be a good idea to have one (and only one) installer generator that supports multiple platforms in order to: 1) Support only one installation program 2) Use the same installation syntax for every platform within CMake Although using native system installer isn't a bad idea, it could be nice to support cross-platform installers. Anyway, I found this idea on the CMake bug/feature tracker. It is not from me. Regards, Félix C. Morency It does not yet exist. If you would like to contribute one, I would be happy to coordinate getting it into the CMake code base. If not, it may just be an idea for some time to come... Some people were talking about using the InstallJammer installer into CPack: http://www.installjammer.com/ WiX does not seem to be portable to other platform than Windows. Neither are the generator targets, so what? Or do you meant that the installers cannot be created when compiling cross-platform like now with NSIS? HS ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] GNU Make warnings
Hi, I don't know if its the right place to post this question but I wondered it there is any way to silently suppress makefile warnings ? E.g.: CMakeFiles/Makefile2:1999: warning: ignoring old commands for target CMakeFiles/Makefile2:1601: warning: overriding commands for target ... It is very annoying since it is detected as a compilation warning by Dart2 and it pollute my logs. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTest XML-RPC submission problem
Hi, Is there an easy and intuitive way to debug generated Build.xml file ? I'm building a specific project and I always have a syntax error in the Build.xml file causing a (-503) error. My file is quite big (~600 lines) for hand debugging. On around 15 projects, this is the only one causing this problem. I'm using CMake 2.4.7 Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CTest XML-RPC submission problem
Hi, I little update to notice you that if I submit the file with the DartClient.jar (Dart2) application, everything is working fine. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CMAKE_SYSTEM_PROCESSOR question
Hi,
I'm using ${CMAKE_SYSTEM_PROCESSOR} in my cmake configure script but
when I call the script with CTest (ctest -S ...), it complains that
this variable is empty. Is there any way to override this ?
Regards,
Félix C. Morency
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Copyonly symlink ?
Hi, With the CONFIGURE_FILES( ... COPYONLY ) command, is it possible to make a symlink to the file on system that supports symlink and really copy the file on system that doesn't support symlink ? If not, is there another way to do this ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CTest Patch
Hi Hendrik, You are right about that because I don't think SVN output is directly analysed by the user. Maybe someone could confirm this. The SVN localization can be modified by changing the LC_MESSAGES env. variable (Unix and Windows). I did some test and it works well. This fix the bug #0005936. It would be wise tho to change the way the SVN executable is called by setting this variable to the english locale before. What do you guys think ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: CTest Patch
Hi, I added usefull information on using SVN with CMake/CTest on the Wiki: http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest#CTest_Scripting Feel free to give me feedback and to add/change the information if its not correct enought. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTest patch
Hi, I made few changes to CTest concerning SVN support. I added support for the french SVN output so that it can handles revision number, automatic updates and etc. I also changed some routine that I think were defectives. Please leave me your comments/suggestions and test the english version so I didn't break anything. Regards, Félix C. Morency cmCTestUpdateHandler.cxx.patch Description: Binary data ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CTest continuous build
Hi, I made a simple CTest script to perform continuous build but there are some things I don't get: 1) CTest is only probing the SVN for change and when there are changes, files aren't updated. Instead, CTest tells me there is an error is some xml file and cannot parse it. 2) CTest does not perform the build when the project is up to date (even if the lib doesn't exist) (I have to verify if it does it when there is changes). Is there any way to tell CTest to always perform the build ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Project, dependendies and Dart2 questions
Hi, I have a program A depending on two internal libraries, B and C. A, B and C are build by CMake script and can be built independantly (A that also build B and C, B only and C only). When generating VS8 solutions, A, B and C are separated into project in the IDE, which is good. If I can, I can only build B or C. I guess its the same thing with my NMake generation and etc. But when submitting A results to the Dart server, it also contains B and C results. Is it possible to separate these when doing submission to Dart ? I would like to do one submission (of the entire A project) but have separated A, B and C results in Dart so the navigation would be easier. Also, I don't want A to contain B and C results in Dart. I want the result to be completly separated. Something like: A (5err, 6warn) B(10err, 9warn) C(0err, 10warn) If this is not possible, what other alternatives exist ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: [Dart] Submission question
Hi Bill, Even if the project hasn't been build, the Experimental project only do a submission without rebuilding. I tried to set the dependencies by hand but it wasn't successfull. Any ideas ? Regards, Félix C. Morency 2007/10/16, Bill Hoffman [EMAIL PROTECTED]: Félix C. Morency wrote: Hi, I generated a VS8 (vsexpress) solution with CMake that contains lots of warnings. I submitted an Experimental build to my testing Dart server but it is always displayed that no errors or warnings have been detected. Any ideas ? You need to clean the project before you run the Experimental. If things are already built, they will not build again, and you will not see the warnings. -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Re: [Dart] Submission question
2007/10/17, Félix C. Morency [EMAIL PROTECTED]: Hi, I have those two lines in my CMakeLists.txt: ENABLE_TESTING() INCLUDE(CTest) And those lines in my CTestConfig.cmake: SET (CTEST_PROJECT_NAME TestProject) SET (CTEST_NIGHTLY_START_TIME 21:00:00 EDT) SET (CTEST_DROP_METHOD xmlrpc) SET (CTEST_DROP_SITE http://localhost:8081;) SET (CTEST_DROP_LOCATION TestProject) SET (CTEST_COMPRESS_SUBMISSION ON) After I run cmake to genetare a VS8 solution, I open it in the IDE and generate the Experimental project. I tried different variations (generate the ALL_BUILD, etc) without success. What am I doing wrong ? Regards, Félix C. Morency 2007/10/17, Bill Hoffman [EMAIL PROTECTED]: Félix C. Morency wrote: Hi Bill, Even if the project hasn't been build, the Experimental project only do a submission without rebuilding. I tried to set the dependencies by hand but it wasn't successfull. Any ideas ? What commands are you using to do the Experimental build? -Bill ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack MacOSX support
Hi, 1. Is there any way to include 3rd party libraries in a generated bundle (.app) with CMake/CPack (.dmg) ? Currently, the 3rd party are out of the bundle and this is quite ungood since the bundle architecture provides resources support. Anyone ever done it before ? 2. The PackageMaker (.dmg) and Bundle generator (.app) support seem limited within CPack. I haven't found a way yet to change the default installation path (from /usr/bin to /Applications) and I think this is quite important. I'm thinking about logging a bug about this issue. The documentation is also lacking informations about those tools. Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack MacOSX support
For the mailing list: David, Thank you for you fast answer. 1. Yes, I actually want to copy some libOne.dylib directly into the bundle so all the required library can be into the .app bundle (at the same place the executable is) and not outside. Another way to say it would be that I want the bundle to be the only existing file where to install every dependencies/ressources so that the .dmg would only contains the bundle. 2. This is good news. I might take a look at the CVS version. When will this updated version of CMake will be officially supported ? Regards, Félix C. Morency 2007/10/11, David Cole [EMAIL PROTECTED]: On 10/11/07, Félix C. Morency [EMAIL PROTECTED] wrote: 1. Is there any way to include 3rd party libraries in a generated bundle (.app) with CMake/CPack (.dmg) ? Currently, the 3rd party are out of the bundle and this is quite ungood since the bundle architecture provides resources support. Anyone ever done it before ? Could you give a concrete example of what you'd like to do here? (Just copy an existing library or resource file into your bundle somewhere?) 2. The PackageMaker (.dmg) and Bundle generator (.app) support seem limited within CPack. I haven't found a way yet to change the default installation path (from /usr/bin to /Applications) and I think this is quite important. I'm thinking about logging a bug about this issue. The documentation is also lacking informations about those tools. In CVS CMake, there is support in the INSTALL(TARGETS command for a separate BUNDLE DESTINATION if the target in question is a Mac bundle application. If you use this with an absolute path, like BUNDLE DESTINATION /Applications/MyApp it should work with make install and also with any generated CPack installers. If you could try it out with CVS CMake and let the list know your results, that would be great. The new INSTALL command arguments are not fully documented yet, but the code should work now. HTH, David Cole ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] RE: CPack MacOSX support
Hi, Actually the library isn't build by CMake. It is a 3rd party library already builded (a .dylib actually) so it doesn't answer the question, sorry. Regards, Félix ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Headers listing in Visual Studio
Thank you all, it does work perfectly.
Félix C. Morency
2007/10/3, Ben Ratzlaff [EMAIL PROTECTED]:
Here is how I do it:
SET (MY_CPP
source files
)
SET (MY_H
header files
)
SOURCE_GROUP (name_of_group
FILES
${MY_CPP}
)
SOURCE_GROUP (name_of_group\\headers
FILES
${MY_H}
)
SET (MY_SRC
${MY_CPP}
${MY_H}
)
# add sources to library
ADD_LIBRARY (${PROJECT}
${MY_SRC}
)
On 10/3/07, Félix C. Morency [EMAIL PROTECTED] wrote:
Hi,
I would like to know how to list the header files in the header
directory in the visual studio IDE. Actually, only the sources and
cmake-related files are listed. I want to be able to see the headers as well
(cosmetic reasons). I searched in the doc and on the net and found nothing.
I tried with ADD_CUSTOM_COMMAND( OUTPUT ${PROJECT_NAME} MAIN_DEPENDENCY
${PROJ_HDRS} ) but only the last header file listed in ${PROJ_HDRS} appears
in the IDE. Could someone help please ?
Also, could we do the same thing with generated MOC files (QT4) ?
Thank you,
Félix C. Morency
___
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] Headers listing in Visual Studio
Hi,
I would like to know how to list the header files in the header directory in
the visual studio IDE. Actually, only the sources and cmake-related files
are listed. I want to be able to see the headers as well (cosmetic reasons).
I searched in the doc and on the net and found nothing. I tried with
ADD_CUSTOM_COMMAND( OUTPUT ${PROJECT_NAME} MAIN_DEPENDENCY ${PROJ_HDRS} )
but only the last header file listed in ${PROJ_HDRS} appears in the IDE.
Could someone help please ?
Also, could we do the same thing with generated MOC files (QT4) ?
Thank you,
Félix C. Morency
___
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Interresting dependency problem
Hi, Thank you for anwsering so fast. 1. What solution do you think is the best: A main master script that knows every dependencies of every projects VS Completly indenpendant build script that we could simply include if we need them and their dependencies ? Please justify. If these are independent solutions, then there is no real choice. If there is such one, then they are not really independent and you could use the simplest approach of a master script. Actually, I would like to be able to build A and B independantly. If I decide to build B, then B and only B is built. If I decide to build A, then B and A are built. This is the actual definition of independance. 2. How can I achieve the first solution with CMake ? (Is it possible ?) You can let cmake write another cmake script with SET statements that you include in yet another cmake script. It sounds like a big configuration file. But how could this solve the src/file1.cpp problem ? Do you have any little practical example ? 3: Is there any better solution that I don't see ? Yes. Every solution comes down to a classic common thing: a development kit for C (used by B) and B (used by A). An automatically written cmake script is one solution (somewhat limiting the dependent build environments to cmake) or something else like pkgconfig, or shell scripts that set environment variables, or whatever. Very much depends on the target audience and personal preferences. Could you please elaborate on an automatically written cmake script. I would like to know more about it and how it can be acheived. The use of pkgconfig is prohibited, just like shell scripts and env. variables. The solution has to be as portable as it can be (win32, linux, macosx, etc.) Thank you again, Félix C. Morency -- Message: 3 Date: Thu, 27 Sep 2007 04:26:32 +0200 From: Hendrik Sattler [EMAIL PROTECTED] Subject: Re: [CMake] Interresting dependency problem To: cmake@cmake.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=utf-8 Am Donnerstag 27 September 2007 schrieb Félix C. Morency: 1. What solution do you think is the best: A main master script that knows every dependencies of every projects VS Completly indenpendant build script that we could simply include if we need them and their dependencies ? Please justify. If these are independent solutions, then there is no real choice. If there is such one, then they are not really independent and you could use the simplest approach of a master script. 2. How can I achieve the first solution with CMake ? (Is it possible ?) You can let cmake write another cmake script with SET statements that you include in yet another cmake script. 3: Is there any better solution that I don't see ? Yes. Every solution comes down to a classic common thing: a development kit for C (used by B) and B (used by A). An automatically written cmake script is one solution (somewhat limiting the dependent build environments to cmake) or something else like pkgconfig, or shell scripts that set environment variables, or whatever. Very much depends on the target audience and personal preferences. HS -- ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Re: Interresting dependency problem
Hi, Thank you all for answering. First, I would like to mention that the pkg-config alternative isn't very portable. Like other already said, it does not work well under Microsoft Windows nor MSVC. Also, all paths are wrote in .pc files which aren't very portable. I think I might have found a solution to this problem today. Here are the basics of the idea: You first need a main configuration file which contains a WORKING_DIR for the executable to be build as well as a PROJECT_INCLUDE_DIR and a PROJECT_LIBRARY_DIR (which are in the WORKING_DIR. For each library, you need two files: - A CMake script that tells the CMake engine how to build the library; - A configuration file that tells the CMake engine who the library is and where to get it dependencies. The trick is in how the CMake engine process the CMake scripts. A feature of CMake's engine is that it can propagate dependencies up-bottom. This is nice if you want to use a master-script approach but isn't usable if you want to be able to build every part of the chain independantly. To acheive such goal, you may want to propagate dependencies bottom-up. As far as I know, this is not doable natively with the CMake engine but can be acheive with the basics I've told earlier. Here's a small example: The project A which contains the A_BuildScript and A_ConfigScript. The project A needs the project B to build. The project B which contains the B_BuildScript and B_ConfigScript. The project B need the third party library C to build. The library C is built by another build system independantly. The B_ConfigScript contains the B project's settings as well as where to find C includes and libraries. Let call the include path PROJECT_B_INCLUDE_DIR. The B_BuildScript contains the instructions on how to build the project Bwith the source files list and what directories to include (refer to PROJECT_B_INClUDE_DIR). The A_ConfigScript contains the A project's settings as well as where to find the B_ConfigScript. Let's call the include path PROJECT_A_INCLUDE_DIR. The A_BuildScript contains the instructions on how to build the project A with the source files life and what directory to include (refer to PROJECT_A_INClUDE_DIR and PROJECT_B_INClUDE_DIR). Depending on how your code has been written, you might need to copy project B's libraries and include to the PROJECT_LIBRARY_DIR and the PROJECT_INCLUDE_DIR. This can be done in the A_BuildScript and B_BuildScriptand processed by calling the CMake's SUBDIRS command. As far as I know, with all the testing I did, this works very well. By including the B_ConfigScript into the A_ConfigScript, you also include the Clibrary w/o having to know whatever about C itself because de dependencies propagate bottom-up. Another good thing is that now every single part of the chain can be build independantly (by processing the A_BuildScript or the B_BuildScript directly). I might write some practical example if I have time or if someone asks for it. Please give me your feedback about it. Thank you for reading me, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack MacOSX bundle
Thank you for answering. I googled the NSStatusItem and I'm not quite sure I understand what you mean. I guess putting the application in the Finder/Application menu could be done without modifying the source code ? I want to put a shortcut/the application to the bundle automaticaly with the installer (.dmg). Of what I understood of my readings, NSStatusItem is for placing the application in the status bar. I am really a MacOSX noob so excuse my misunderstanding Regards, Félix C. Morency 2007/9/26, Sean McBride [EMAIL PROTECTED]: On 9/25/07 12:06 PM, Félix C. Morency said: I'm trying to create a MacOSX bundle with my application. So far, everything is working (.dmg generation) except the fact that the application is always installed in /usr/bin. Is there any way to install it in the application menu ? I'm far from being a mac expert so I would need help please. If you want something to be in the application menu, then you need to make an NSStatusItem, not an application. Google NSStatusItem. -- Sean McBride, B. Eng [EMAIL PROTECTED] Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Interresting dependency problem
Hi, I have a particular situation that I would like you to analyze to help me find the best solution possible. I have a project A, a project B and an external dependency called C. The project B depends directly on C. The project A needs the projects B to build but does not want to know about its dependencies (C). So, A--B--C and A doesn't know anything about C. Of what I tought, there are two solution approaches to this problem: 1. The project A and B cmake script are completly independant; B is able to build itself alone and A simply include B's script that contains the link to the dependency C. 2. There is a master script that knows every dependencies (in our case, C) and which build A and B calling the subdir command to execute their proper scripts. A and B script knows nothing about C in their proper scripts. I did some tests and the second solution is working fine with CMake. Every depencies are propagated in the three like a charm. However, I have problem with the first one and I would like if it would be possible to acheive. The problem is when I include the B script, the CMake engine is searching for the B files in the A paths. Example: A source directory is: src/file1.cpp B source directory is: src/file2.cpp file2.cpp is searched in the src/ directory of project A. Of course, the file isn't found and CMake is generating an error. Here's come the questions: 1. What solution do you think is the best: A main master script that knows every dependencies of every projects VS Completly indenpendant build script that we could simply include if we need them and their dependencies ? Please justify. 2. How can I achieve the first solution with CMake ? (Is it possible ?) 3: Is there any better solution that I don't see ? I would really like to know what you think about this problematic. Regard, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] CPack MacOSX bundle
Hi, I'm trying to create a MacOSX bundle with my application. So far, everything is working (.dmg generation) except the fact that the application is always installed in /usr/bin. Is there any way to install it in the application menu ? I'm far from being a mac expert so I would need help please. Thank you, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
[CMake] Library linking cmake's bug with QT4
Hi, I am trying to build a library with cmake using QT4 tools (moc, wrap) using a master cmake script and lib/project related subscript. The thing is that I have a build error then the one of the library (the one that uses QT4) tries to link. Here's the log: Linking CXX static library /Users/fcmorency/Documents/foo/lib/libPETHardwareHandlers.a Error processing file:CMakeFiles/PETHardwareHandlers.dir/cmake_clean_target.cmake Error opening link script CMakeFiles/PETHardwareHandlers.dir/link.txt make[2]: *** [/Users/fcmorency/Documents/foo/lib/libPETHardwareHandlers.a] Error 1 make[1]: *** [Librairies/Branches/Lib_cmake/PETHardwareHandlers/CMakeFiles/PETHardwareHandlers.dir/all] Error 2 make: *** [all] Error 2 Also, If I place myself in the Librairies/Branches/Lib_cmake/PETHardwareHandlers/ directory and run the linking command myself, which would be cmake -E cmake_link_script CMakeFiles/PETHardwareHandlers.dir/link.txt, it does link well and build the lib. Any hints ? Regards, Félix C. Morency ___ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake
