[cmake-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
Hey,
I worked on a patch for supporting dep-tracking with GetPrequesites when
cross-compiling for Windows with MinGW.
While doing this I noticed neither WIN32 nor CMAKE_CROSSCOMPILING are
defined at CPack time, why?
This is the reason my code in the patch is not in the WIN32 block above and
I couldn't guess the gp_tool correctly.
A hardcoded list of .dll names is for sure not really elegant, but I don't
know of any way to check if a required .dll is a windows system library. On
Linux of course there are no Windows system dlls in a certain folder and
the absence of such a dll doesn't mean anything either because an import
lib (.dll.a usually) is enough to link against.
The patch is probably not ready to be upstreamed but I'm happy to fix
issues or follow a nicer approach if you point me to it.
Best regards,
Dominik
diff --git a/Modules/GetPrerequisites.cmake b/Modules/GetPrerequisites.cmake
index 8761f40..304a0d6 100644
--- a/Modules/GetPrerequisites.cmake
+++ b/Modules/GetPrerequisites.cmake
@@ -476,6 +476,56 @@ function(gp_resolved_file_type original_file file exepath dirs type_var)
endif(UNIX)
endif(WIN32)
+set(windows_system_libraries
+advapi32.dll
+cfgmgr32.dll
+comctl32.dll
+comdlg32.dll
+crypt32.dll
+ddraw.dll
+dnsapi.dll
+dsound.dll
+gdi32.dll
+gdiplus.dll
+glu32.dll
+glut32.dll
+imm32.dll
+iphlpapi.dll
+kernel32.dll
+mscms.dll
+mscoree.dll
+msimg32.dll
+msvcr71.dll
+msvcr80.dll
+msvcr90.dll
+msvcrt.dll
+mswsock.dll
+ole32.dll
+oleaut32.dll
+opengl32.dll
+psapi.dll
+rpcrt4.dll
+secur32.dll
+setupapi.dll
+shell32.dll
+shlwapi.dll
+user32.dll
+usp10.dll
+version.dll
+wininet.dll
+winmm.dll
+wldap32.dll
+ws2_32.dll
+wsock32.dll
+)
+
+string(TOLOWER ${file} file_lower)
+foreach(windows_system_library ${windows_system_libraries})
+if( ${file_lower} STREQUAL ${windows_system_library})
+set(is_system 1)
+endif()
+endforeach()
+
if(NOT is_system)
get_filename_component(original_path ${original_lower} PATH)
get_filename_component(path ${lower} PATH)
@@ -573,6 +623,7 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa
endif(WIN32 AND NOT UNIX)
endif(${gp_tool} STREQUAL )
+ set(gp_tool objdump)
set(gp_tool_known 0)
if(${gp_tool} STREQUAL ldd)
@@ -603,6 +654,15 @@ function(get_prerequisites target prerequisites_var exclude_system recurse exepa
set(ENV{VS_UNICODE_OUTPUT} ) # Block extra output from inside VS IDE.
endif(${gp_tool} STREQUAL dumpbin)
+ if(${gp_tool} STREQUAL objdump)
+set(gp_cmd_args -p)
+set(gp_regex .*DLL Name: ([^ ]*[Dd][Ll][Ll])${eol_char}$)
+set(gp_regex_error )
+set(gp_regex_fallback )
+set(gp_regex_cmp_count 0)
+set(gp_tool_known 1)
+ endif()
+
if(NOT gp_tool_known)
message(STATUS warning: gp_tool='${gp_tool}' is an unknown tool...)
message(STATUS CMake function get_prerequisites needs more code to handle '${gp_tool}')
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
Hey Eric, thanks for the quick reply! On Tue, Mar 6, 2012 at 1:16 PM, Eric Noulard eric.noul...@gmail.com wrote: While doing this I noticed neither WIN32 nor CMAKE_CROSSCOMPILING are defined at CPack time, why? May be because no one did really tackle the cross-packaging problem? Cross-compiling is one thing, cross packaging is another one (which may be difficult or impossible in the general case). Ah okay :-) This is the reason my code in the patch is not in the WIN32 block above and I couldn't guess the gp_tool correctly. In order to be sure that nothing else is breaking you can try to [manually] add the missing definition in the CPackConfig.cmake file. This file is loaded by CPack at CPack-time so that any definitions in there will be seen during CPack run. Went fine. An alternative would be to do it in a CPack Project Config file: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 Might make sense, indeed. That way you could explicitly say if you want to cross-package or not. By the way how does GetPrerequisite get called ? Is it does through BundleUtilities? I'm not using those so, are they called at [CPack-]install time ? Yes. I'm using DeployQt4, which uses BundleUtilities, which use GetPrerequisites. A hardcoded list of .dll names is for sure not really elegant, but I don't know of any way to check if a required .dll is a windows system library. On Linux of course there are no Windows system dlls in a certain folder and the absence of such a dll doesn't mean anything either because an import lib (.dll.a usually) is enough to link against. The patch is probably not ready to be upstreamed but I'm happy to fix issues or follow a nicer approach if you point me to it. Before going on may be you could explain us what kind of cross-packaging your are targeting: NSIS, Archive generator, etc... NSIS is the one I'm aiming for :-) Setting WIN32 and/or CMAKE_CROSSCOMPILING may be done in CPack list interpreter but it remains to be seen whether it would be enough in order to achieve what you want. I think so, it already works when gp_tool is manually set to objdump! -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org Best regards, Dominik -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
2012/3/6 Dominik Schmidt do...@tomahawk-player.org: Hey Eric, thanks for the quick reply! You are welcome. This is the reason my code in the patch is not in the WIN32 block above and I couldn't guess the gp_tool correctly. In order to be sure that nothing else is breaking you can try to [manually] add the missing definition in the CPackConfig.cmake file. This file is loaded by CPack at CPack-time so that any definitions in there will be seen during CPack run. Went fine. An alternative would be to do it in a CPack Project Config file: http://www.cmake.org/Wiki/CMake:CPackPackageGenerators#Overall_usage_.28common_to_all_generators.29 Might make sense, indeed. That way you could explicitly say if you want to cross-package or not. It is even necessary for more than just testing because the CPackConfig.cmake file may be overwritten by CPack next time you change your CMakeLists.txt. CPackConfig.cmake is generated by the include(CPack) in your CMakeLists.txt. Ultimately it may be useful to configure_file your CPackProjectConfig.cmake.[in] and put some generated logic in it depending on any CMake variable. The patch is probably not ready to be upstreamed but I'm happy to fix issues or follow a nicer approach if you point me to it. Before going on may be you could explain us what kind of cross-packaging your are targeting: NSIS, Archive generator, etc... NSIS is the one I'm aiming for :-) Ok. Setting WIN32 and/or CMAKE_CROSSCOMPILING may be done in CPack list interpreter but it remains to be seen whether it would be enough in order to achieve what you want. I think so, it already works when gp_tool is manually set to objdump! If you manage to do that kind of cross-packaging it could be worth a page on the Wiki. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Doxygen documentation
On 3/6/2012 2:23 AM, Yury G. Kudryashov wrote: Hi! I've just found that there are two doxygen configs in cmake source tree: * cmake/doxygen.config I think you can remove this one. * cmake/Utilities/Doxygen/* VTK magic The second one can be enabled by BUILD_DOCUMENTATION but doc_makeall.sh references some VTK_* variables. Which one should I use/fix/..? ...and remove VTK references of course. Those are left from *way* back. Thanks, -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Build faild on Darwin? Don't know why?
On 3/6/2012 2:43 AM, Eric Noulard wrote: Did you see this bug report: http://public.kitware.com/Bug/view.php?id=13017 this may explain the sporadic failure on MacOS? Now I see that there is already a retry loop, [...] // since we get random dashboard failures with this one // try running it more than once int numTries = 4; bool res = false; while(numTries 0) [...] but if anti-virus is the reason for hdiutil failure may be there is a way to tell the anti-virus to stay away from mounted image? Our mac's do not have anti-virus. So, that is not the problem -Bill -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013019]: The ZIP package generator does not find the files when CPACK_PACKAGING_INSTALL_PREFIX is set
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13019
==
Reported By:Harald Winroth
Assigned To:
==
Project:CMake
Issue ID: 13019
Category: CPack
Reproducibility:always
Severity: major
Priority: normal
Status: new
==
Date Submitted: 2012-03-06 10:00 EST
Last Modified: 2012-03-06 10:00 EST
==
Summary:The ZIP package generator does not find the files
when CPACK_PACKAGING_INSTALL_PREFIX is set
Description:
I use components and generate one binary package ZIP for each component. If
CPACK_PACKAGING_INSTALL_PREFIX is not set, everything works as expected. But
when I set CPACK_PACKAGING_INSTALL_PREFIX to /MyPrefix, the package generator
is unable to find the files when compressing, resulting in the error message:
CPack: Create package
1CPack Error: ERROR while packaging files: archive_read_disk_entry_from_file:
(Empty error message)
1CPack Error: Problem compressing the directory
Steps to Reproduce:
In CMakeLists.txt:
set (CPACK_COMPONENTS_ALL core)
set (CPACK_ARCHIVE_COMPONENT_INSTALL 1)
In CPackProjectConfig.cmake:
set (CPACK_PACKAGING_INSTALL_PREFIX /MyPrefix)
C:\Program Files\CMake 2.8\bin\cpack.exe -C Debug --config ./CPackConfig.cmake
Additional Information:
In Source\CPack\cmCPackGenerator.cxx line 849:
localFileName =
cmSystemTools::RelativePath(InstallPrefix, fit-c_str());
localFileName =
localFileName.substr(localFileName.find('/')+1,
std::string::npos);
Now, when CPACK_PACKAGING_INSTALL_PREFIX is NOT set, fit is
C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core//bin/MyLib.dll and
InstallPrefix is C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core/”.
Note the double slash in fit, it looks strange. After line 849 has executed,
localFileName is /bin/MyLib.dll”. Then, line 851 removes the leading slash,
leaving bin/MyLib.dll” in localFileName, and everything works.
However, if I set CPACK_PACKAGING_INSTALL_PREFIX to /MyPrefix, then at line
849 above fit is
C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core/MyPrefix/bin/MyLib.dll
(note: no double slash in the path) and InstallPrefix is
C:/MyPath/_CPack_Packages/win32/ZIP/MyPackage-win32/core/MyPrefix. Line 489
sets localFileName to “bin/MyLib.dll” (which is the correct file name), but
then line 851 strips of “bin/”, leaving just “MyLib.dll” in
localFileName. That path will not be found later on.
But there also seems to be other problems in the code. The
CPACK_PACKAGING_INSTALL_PREFIX doesn't seem to be taken into account futher down
when the ZIP archive is created. Is the prefix parameter of the AddFile call
suppose to be used for this?
==
Issue History
Date ModifiedUsername FieldChange
==
2012-03-06 10:00 Harald Winroth New Issue
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Doxygen documentation
Brad King wrote: On 3/6/2012 2:23 AM, Yury G. Kudryashov wrote: Hi! I've just found that there are two doxygen configs in cmake source tree: * cmake/doxygen.config I think you can remove this one. * cmake/Utilities/Doxygen/* VTK magic The second one can be enabled by BUILD_DOCUMENTATION but doc_makeall.sh references some VTK_* variables. Which one should I use/fix/..? ...and remove VTK references of course. Those are left from *way* back. Did I understand correctly that I should remove the first one and work on the second one? Where can I find the scripts referenced by the second one? In VTK source tree? Do we really need those scripts? From doc_makeall.sh.in: # INTERMEDIATE_DOX_DIR: # Directory where the intermediate Doxygen files should be stored (mainly # these headers files converted from the VTK format to the Doxygen format). What is the VTK format? Doesn't cmake use plain doxygen format? -- Yury G. Kudryashov, mailto: ur...@mccme.ru -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013020]: Custom commands after generation
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13020 == Reported By:Petr Kmoch Assigned To: == Project:CMake Issue ID: 13020 Category: CMake Reproducibility:N/A Severity: minor Priority: normal Status: new == Date Submitted: 2012-03-06 16:44 CET Last Modified: 2012-03-06 16:44 CET == Summary:Custom commands after generation Description: In multiple situations, I have run into a need to perform some processing after CMake finishes generating the buildsystem (e.g. need to post-process the generated .sln file). Could perhaps add_custom_command() be expanded to allow a third form, like this? preadd_custom_command(POST_GENERATION COMMAND command1 [ARGS] [args1...] [COMMAND command2 [ARGS] [args2...] ...] [WORKING_DIRECTORY dir] [VERBATIM])/pre It's not enough to have a wrapper script around CMake, as this doesn't get run when CMake re-runs automatically during build because a CMakeList changed. == Issue History Date ModifiedUsername FieldChange == 2012-03-06 16:44 Petr Kmoch New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Doxygen documentation
On 3/6/2012 10:10 AM, Yury G. Kudryashov wrote: Did I understand correctly that I should remove the first one and work on the second one? Where can I find the scripts referenced by the second one? In VTK source tree? Do we really need those scripts? From doc_makeall.sh.in: # INTERMEDIATE_DOX_DIR: # Directory where the intermediate Doxygen files should be stored (mainly # these headers files converted from the VTK format to the Doxygen format). What is the VTK format? Doesn't cmake use plain doxygen format? Perhaps it is better to ignore my initial response. I haven't generated the doxygen pages in probably 10 years. I think Nicolas (CCed) got them working about a year ago. The BUILD_DOCUMENTATION option enables it. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja windows
On Tue, Mar 06, 2012 at 11:44:46AM -0500, Bill Hoffman wrote: What is the current status of ninja windows? I would like to setup a dashboard for this, however, the ninja code for windows does not seem to be on the stage for CMake right now. Is there a way to get it on the stage? Or is it too far from being useful to be on the stage at this point? The Ninja generator is disabled on Windows as it still doesn't yet work correctly with Ninja's master branch. It works to some degree with someone else's branch, but one of the required features on that branch (response file support) was recently merged into Ninja master, so hopefully someone on Windows will be able to add the necessary support to CMake soon. I would hold off on setting up a dashboard for Windows until we can at least build CMake with Ninja master. I have been asking Windows developers to enable the generator locally for their own development by commenting out the IF(NOT WIN32) block. Perhaps once we set up Windows dashboards it would be better to introduce an internal variable (CMAKE_USE_NINJA?) which can be used to enable this generator on Windows, and have the dashboards use it. Thanks, -- Peter -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja windows
On 3/6/2012 12:17 PM, Peter Collingbourne wrote: The Ninja generator is disabled on Windows as it still doesn't yet work correctly with Ninja's master branch. It works to some degree with someone else's branch, but one of the required features on that branch (response file support) was recently merged into Ninja master, so hopefully someone on Windows will be able to add the necessary support to CMake soon. I would hold off on setting up a dashboard for Windows until we can at least build CMake with Ninja master. I am a bit confused. What are the features on someone else's branch that the CMake generator needs? What will it take to get this: http://sourceforge.net/projects/cmakescript/files/cmake-2.8.7.20120202-Ninja.exe into the CMake source tree? I would be OK, with a non-standard ninja as long as those patches are eventually going to be in ninja. I don't like having ninja windows cmake support outside of the main cmake dev tree. Could we do this: 1. integrate cmake windows ninja support into next 2. run a dashboard that uses a given ninja binary? My goal would be to make sure cmake windows ninja keeps building and working and other ninja work does not break the existing cmake windows support. I have been asking Windows developers to enable the generator locally for their own development by commenting out the IF(NOT WIN32) block. Perhaps once we set up Windows dashboards it would be better to introduce an internal variable (CMAKE_USE_NINJA?) which can be used to enable this generator on Windows, and have the dashboards use it. I would rather have it on by default and print some warning if it finds the wrong ninja, one that does not have the required patches. -Bill -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Ninja windows
On 3/6/2012 1:29 PM, Peter Collingbourne wrote: We can certainly do that, but the ninja binary would need to be switched as soon as we get around to using rspfile in Ninja (and no sooner). OK, so is there a ninja binary that I can download right now that will work if I change the cmake files for cmake to build the ninja generator on windows? If so, where is it? My idea is to try it on my machine. If it works I will push the change into next that enables ninja on windows and setup a dashboard that pulls ninja from that spot each night. When cmake is changed to work with master ninja if someone updates that binary, then it will pull that and just work. That is what I have been doing with jom. -Bill -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013022]: FindCxxTest.cmake does not support CxxTest version 4 (patch attached)
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13022 == Reported By:Droscy Assigned To: == Project:CMake Issue ID: 13022 Category: Modules Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-03-06 17:21 EST Last Modified: 2012-03-06 17:21 EST == Summary:FindCxxTest.cmake does not support CxxTest version 4 (patch attached) Description: FindCxxTest.cmake doesn't support CxxTest version 4 where the Perl generator has been deleted and the Python generator is installed without the .py extension. Attached to this email the simple patch that I've written for Debian in order to make the module compatible with the new cxxtest package. == Issue History Date ModifiedUsername FieldChange == 2012-03-06 17:21 Droscy New Issue 2012-03-06 17:21 Droscy File Added: cxxtestgen_name_fix.patch == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013023]: implementation of new CHECK_C_INLINE macro
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=13023
==
Reported By:Christopher Sean Morrison
Assigned To:
==
Project:CMake
Issue ID: 13023
Category: CMake
Reproducibility:N/A
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2012-03-07 01:32 EST
Last Modified: 2012-03-07 01:32 EST
==
Summary:implementation of new CHECK_C_INLINE macro
Description:
I've implemented a CHECK_C_INLINE macro that detects what keyword, if any, is
used for inlining C functions. The check is very similar to autoconf's
AC_C_INLINE portability macro, testing various methods to find one that works.
The macro takes a variable from the caller and utilizes caching so tests are
only run when necessary.
Steps to Reproduce:
# using the new macro looks like this:
CHECK_C_INLINE(C_INLINE)
if(NOT C_INLINE STREQUAL inline)
add_definitions(-Dinline=${C_INLINE})
endif(NOT C_INLINE STREQUAL inline)
That has the convenient behavior of renaming instances of inline to an
alternate available keyword or to nothing/empty if none are supported.
Additional Information:
This is a work-in-progress, but I'll be happy to maintain the macro if need be.
A quick search indicates such a macro would be of general use suitable for
inclusion as a new built-in macro. Constructive feedback is always welcome, of
course.
==
Issue History
Date ModifiedUsername FieldChange
==
2012-03-07 01:32 Christopher Sean MorrisonNew Issue
2012-03-07 01:32 Christopher Sean MorrisonFile Added: CheckCInline.cmake
==
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] POST_BUILD ALL_BUILD
On 03/06/2012 02:34 AM, Christopher Piekarski wrote: Hello All, I am trying to attach a custom POST_BUILD command to the ALL_BUILD target. I've tried adding the following at the bottom of my root CMakeLists.txt file but the Post Event never shows up in Visual Studio. I have been able to get it to work for sub projects, just not ALL_BUILD. Has anyone gotten this to work? add_custom_command(TARGET ALL_BUILD POST_BUILD COMMAND python27.exe brand.py COMMENT Branding VS debug build ) AFAIK, that's not possible ATM, see also [1]. Instead, you could use a custom target ADD_CUSTOM_TARGET(brand ALL COMMAND python27.exe brand.py COMMENT Branding VS debug build ) ADD_DEPENDENCIES(brand target1 ... targetn) and list your project's targets as prerequisites in order to ensure that brand is built last. For convenience, you might consider to provide wrappers for ADD_LIBRARY() and ADD_EXECUTABLE() which add the respective target to a global property, and use the latter's value for the above-noted ADD_DEPENDENCIES() at the end of your top-level CMakeLists.txt. Regards, Michael [1] http://public.kitware.com/Bug/view.php?id=8438 -- 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] VS2010: /subsystem:console only in debug build
Hi, I'd like to suppress the console, but only in release builds. What's the official way to do that? add_executable(... win32 ...) doesn't work, because it switches off the console in debug builds. When I set LINKER_FLAGS_RELEASE to /subsystem:windows, I can suppress the console in the release builds. However, the Properties window in VS2010 still displays Console (/SUBSYSTEM:CONSOLE) in the linker settings, and has two entries in the command line: /SUBSYSTEM:CONSOLE and /subsystem:windows. Only the latter seems to count. When I set LINKER_FLAGS_RELEASE to /SUBSYSTEM:WINDOWS, CMake just drops it, and only retains /SUBSYSTEM:CONSOLE in the linker flags. It seems to me that CMake recognizes /SUBSYSTEM:WINDOWS, but chooses to ignore it for some reason. The fact that /subsystem:windows works the way it does seems like a bug. So what's the proper way to achieve what I want? I'm using CMake 2.8.7 on Win 7 with VS2010. Cheers Andreas -- 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] failing target
On 03/06/2012 07:23 AM, Michael Hertling wrote: On 03/05/2012 05:59 PM, Andrea Crotti wrote: I'm having the following behaviour, and I can't quite understand the error message: .. Built target psi.utility_install .. make[3]: *** No rule to make target `psi.utility_install', needed by `CMakeFiles/install_all_eggs'. Stop. make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2 make[1]: *** [CMakeFiles/unzip_all_eggs.dir/rule] Error 2 make: *** [unzip_all_eggs] Error 2 So first it builds successfully psi.utility_install and then it complains that there are no rules to make it. Who is right then and what could cause such a problem? This is happening on a strange Linux machine, on Windows with MinGW it's working (strangely).. Could you boil down your project to a minimal and self-sufficient example which exhibits this behavior for further investigations? Regards, Michael -- That's quite tricky unfortunately, I hoped that someone saw something similar already and could give me a hint.. Anyway that machine is not a priority at the moment I'll just see later when it's more stable. -- 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] VS2010: /subsystem:console only in debug build
Hi Andreas, as far as I know, your only chance to achieve this is by modifying your source code by adding #ifndef NDEBUG #pragma comment(linker, /SUBSYSTEM:CONSOLE) #endif Using add_executable(... win32 ...) is correct because the pragma statement will override the behaviour in debug mode (in my example in all but release builds) I hope this helps. Regards, Hauke On Tue, Mar 6, 2012 at 11:55 AM, Andreas Haferburg ahaferb...@scopis.comwrote: Hi, I'd like to suppress the console, but only in release builds. What's the official way to do that? add_executable(... win32 ...) doesn't work, because it switches off the console in debug builds. When I set LINKER_FLAGS_RELEASE to /subsystem:windows, I can suppress the console in the release builds. However, the Properties window in VS2010 still displays Console (/SUBSYSTEM:CONSOLE) in the linker settings, and has two entries in the command line: /SUBSYSTEM:CONSOLE and /subsystem:windows. Only the latter seems to count. When I set LINKER_FLAGS_RELEASE to /SUBSYSTEM:WINDOWS, CMake just drops it, and only retains /SUBSYSTEM:CONSOLE in the linker flags. It seems to me that CMake recognizes /SUBSYSTEM:WINDOWS, but chooses to ignore it for some reason. The fact that /subsystem:windows works the way it does seems like a bug. So what's the proper way to achieve what I want? I'm using CMake 2.8.7 on Win 7 with VS2010. Cheers Andreas -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/** opensource/opensource.htmlhttp://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/**CMake_FAQhttp://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/**listinfo/cmakehttp://www.cmake.org/mailman/listinfo/cmake -- 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] failing target
On 03/06/2012 12:21 PM, Andrea Crotti wrote: On 03/06/2012 07:23 AM, Michael Hertling wrote: On 03/05/2012 05:59 PM, Andrea Crotti wrote: I'm having the following behaviour, and I can't quite understand the error message: .. Built target psi.utility_install .. make[3]: *** No rule to make target `psi.utility_install', needed by `CMakeFiles/install_all_eggs'. Stop. make[2]: *** [CMakeFiles/install_all_eggs.dir/all] Error 2 make[1]: *** [CMakeFiles/unzip_all_eggs.dir/rule] Error 2 make: *** [unzip_all_eggs] Error 2 So first it builds successfully psi.utility_install and then it complains that there are no rules to make it. Who is right then and what could cause such a problem? This is happening on a strange Linux machine, on Windows with MinGW it's working (strangely).. Could you boil down your project to a minimal and self-sufficient example which exhibits this behavior for further investigations? Regards, Michael -- That's quite tricky unfortunately, I hoped that someone saw something similar already and could give me a hint.. Anyway that machine is not a priority at the moment I'll just see later when it's more stable. Could you post the lines which define those targets psi.utility_install and install_all_eggs, or is this quite tricky, too? Do these lines stem from the same CMakeLists.txt? IIRC, the no rule to make... needed by error occurs when there's something wrong with the DEPENDS clause of ADD_CUSTOM_COMMAND/TARGET(). Regards, Michael -- 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] failing target
On 03/06/2012 01:45 PM, Michael Hertling wrote:
Could you post the lines which define those targets psi.utility_install
and install_all_eggs, or is this quite tricky, too? Do these lines stem
from the same CMakeLists.txt? IIRC, the no rule to make... needed by
error occurs when there's something wrong with the DEPENDS clause of
ADD_CUSTOM_COMMAND/TARGET().
Regards,
Michael
Well I think it's something related to the platform, because both on my
Linux
box and windows it works perfectly.
This is the interesting part anyway:
foreach(egg ${egg_list})
#TODO: now I need to replace the name with only the last part of the path
get_filename_component(egg_name ${egg} NAME)
set(egg_install ${egg_name}_install)
# generate the list of targets to create more easily dependencies
list(APPEND egg_install_list ${egg_install})
add_custom_target(${egg_install}
COMMAND ${PYTHON_EXECUTABLE} setup.py -q bdist_egg -d
${EGG_BUILD_DIRECTORY}
WORKING_DIRECTORY ${egg}
)
endforeach()
add_custom_target(install_all_eggs
DEPENDS ${egg_install_list}
)
#TODO: add this target to the dependencies of run and packing if it works
add_custom_target(unzip_all_eggs
# unzip the eggs and clean up the zips
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${EGG_BUILD_DIRECTORY}
${EGG_UNZIPPED_DIRECTORY}
# copy the two run files in the final destination
COMMAND ${CMAKE_COMMAND} -E copy ${EGG_BUILD_DIRECTORY}/${RUNNER}
${EGG_UNZIPPED_DIRECTORY}/${RUNNER}
COMMAND ${CMAKE_COMMAND} -E copy ${EGG_BUILD_DIRECTORY}/${C_RUNNER}
${EGG_UNZIPPED_DIRECTORY}/${C_RUNNER}
DEPENDS install_all_eggs
)
sdo the targets are generated at cmake-time reading from a file and then
there are few more targets that depend on
all of them.
Is there anything wrong in this part?
--
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] transitive linking with separate projects
Hei hei, we faced a build problem with transitive linking of separate projects where I can't find the right solution on my own. I hope someone can give me a hint. I prepared a test case with two libraries libfoo and libbar and an application baz. libfoo is on his own, libbar calls a function from libfoo and baz calls the function from libbar calling libfoo. So the dependencies are like this: baz - libbar - libfoo baz doesn't need to know of libfoo because it just calls libbar, so I thought. Now the projects are separated and both libraries come with cmake package configuration files. For linking libfoo in libbar I do the following: find_package(FOO) target_link_libraries(BAR_SRC foo-shared) foo-shared is the target libfoo exports via cmake package configuration. This works and ldd shows libbar is correctly linked against libfoo. Now when compiling baz I more or less do the same: find_package(BAR) target_link_libraries(BAZ_SRC bar-shared) However building baz fails with the following error: % make [100%] Building C object src/CMakeFiles/baz.dir/baz.c.o Linking C executable baz /usr/bin/ld: cannot find -lfoo-shared collect2: ld returned 1 exit status make[2]: *** [src/baz] Fehler 1 make[1]: *** [src/CMakeFiles/baz.dir/all] Fehler 2 make: *** [all] Fehler 2 It seems like cmake tries to link against libfoo here but does not know anything about it. If I add find_package(FOO) to baz obviously the target is imported from libfoo cmake package files. The question is, if I know nothing about the requirements of libbar and want to avoid adding find_package statements for those requirements to baz, how would I do this? I put all the code on GitHub, so if someone maybe could have a look? https://github.com/LeSpocky/libfoo https://github.com/LeSpocky/libbar https://github.com/LeSpocky/baz Greets Alex -- »With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably.« (Jean-Luc Picard, quoting Judge Aaron Satie) *** GnuPG-FP: 02C8 A590 7FE5 CA5F 3601 D1D5 8FBA 7744 CC87 10D0 *** -- 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] Updated: CMake 2.8.7-1
CMake 2.8.7-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - improved Eclipse support - incremental improvements to the AUTOMOC feature added in the previous release - more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512) - file(...) and string(...) command additions for computing hash values - added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command - new module: DeployQt4 - and, as always, various minor bug fixes Similar to the previous release, we do not have pre-built binaries for the SunOS anymore. However, now we have two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. There was a bit of a network connectivity snag in building the binaries for the AIX platform today... Because of this, the tarballs for AIX will not be available until sometime next week. Following is the complete list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Thanks for using CMake! -Bill Changes in CMake 2.8.7 (since 2.8.7-rc2) None Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1) Alex Neundorf (5): automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE automoc: improved warning message in relaxed mode Remove trailing whitespace Add comment about one more problem of the C depency scanner. fix #12262: dependency scanning for ASM files Bill Hoffman (1): Fix the case where cmake --build failed with two project cmds in one file. Brad King (11): KWSys: Correctly handle empty environment variables FortranCInterface: Work around mingw32-make trouble with parens Xcode: Create separate rerun dependencies for subprojects (#12616) Fix Intel Fortran .vfproj files for VS 10 HP: Drive shared library linking with compiler front end Follow all dependencies of shared library private dependencies Do not link private dependent shared libraries on OS X 10.4 Avoid clobbering variable 'OUTPUT' in compiler tests (#12628) Fix and simplify Fortran test compiler compatibility check CTest: Recognize Intel errors without space before colon (#12627) Windows-GNU: Remove extra quotes in GNUtoMS rule variable David Cole (4): Release: Increase timeout for slow-testing cygwin build Modules: Use windres as rc compiler base name for cross-compiles (#12480) Tests: Only really run MFC test if we can build MFC apps (#11213) FindBoost: Quote possibly empty string argument (#12273) Eric NOULARD (1): CPackRPM fix #0012608 and unoticed related bug Johan Fänge (1): CMake: Fix progress reporting for custom targets (#12441) Mike McQuaid (2): Unset configurations variable when no build type. Improve component support and output indentation. Raphael Kubo da Costa (2): Remove the apparently outdated README in Source/QtDialog. QtDialog: Set Ctrl+Q as the shortcut for quitting the program. Tim Gallagher (2): FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624) FindLAPACK: List thread libs to avoid link errors (#12625) Valat Sébastien (1): CTest: Do not get CDash version without drop site (#12618) Changes in CMake 2.8.7-rc1 (since 2.8.6) Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (60): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders if not supported Eclipse: better message when Eclipse version could not be determined automoc:run moc on the header if the source file contains include foo.moc Add copyright notices automoc: always run moc on the cpp file if there is a foo.moc included Eclipse: add virtual folder for each target Eclipse: move code for generating links to projects into separate function Eclipse: move code for generating links to targets into separate function Eclipse: add Build and Clean targets to targets Eclipse: detect number of CPUs, set CMAKE_ECLIPSE_MAKE_ARGUMENTS accordigly Eclipse: fix #12417, don't create wrong src pathentries FindLibXslt: also search libexslt and xsltproc don't crash in automoc with
Re: [CMake] Where can I get the latest version of CMake for cygwin?
On 3/3/2012 10:13 AM, marco atzeri wrote: Bill, a simple RFU (request for upload) at cygwin-apps mailing list, with the link at your files http://www.cmake.org/files/v2.8/cmake-2.8.7-1.tar.bz2 http://www.cmake.org/files/v2.8/cmake-2.8.7-1-src.tar.bz2 will allow a larger audience and the correct deployment of your package. ' Yes, I know. I will try to be quicker about it in the future. It is there now. -Bill -- 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] failing target
On 03/06/2012 02:47 PM, Andrea Crotti wrote:
On 03/06/2012 01:45 PM, Michael Hertling wrote:
Could you post the lines which define those targets psi.utility_install
and install_all_eggs, or is this quite tricky, too? Do these lines stem
from the same CMakeLists.txt? IIRC, the no rule to make... needed by
error occurs when there's something wrong with the DEPENDS clause of
ADD_CUSTOM_COMMAND/TARGET().
Regards,
Michael
Well I think it's something related to the platform, because both on my
Linux
box and windows it works perfectly.
This is the interesting part anyway:
foreach(egg ${egg_list})
#TODO: now I need to replace the name with only the last part of the path
get_filename_component(egg_name ${egg} NAME)
set(egg_install ${egg_name}_install)
# generate the list of targets to create more easily dependencies
list(APPEND egg_install_list ${egg_install})
add_custom_target(${egg_install}
COMMAND ${PYTHON_EXECUTABLE} setup.py -q bdist_egg -d
${EGG_BUILD_DIRECTORY}
WORKING_DIRECTORY ${egg}
)
endforeach()
add_custom_target(install_all_eggs
DEPENDS ${egg_install_list}
)
#TODO: add this target to the dependencies of run and packing if it works
add_custom_target(unzip_all_eggs
# unzip the eggs and clean up the zips
COMMAND ${PYTHON_EXECUTABLE} ${UNZIP_SCRIPT} ${EGG_BUILD_DIRECTORY}
${EGG_UNZIPPED_DIRECTORY}
# copy the two run files in the final destination
COMMAND ${CMAKE_COMMAND} -E copy ${EGG_BUILD_DIRECTORY}/${RUNNER}
${EGG_UNZIPPED_DIRECTORY}/${RUNNER}
COMMAND ${CMAKE_COMMAND} -E copy ${EGG_BUILD_DIRECTORY}/${C_RUNNER}
${EGG_UNZIPPED_DIRECTORY}/${C_RUNNER}
DEPENDS install_all_eggs
)
sdo the targets are generated at cmake-time reading from a file and then
there are few more targets that depend on
all of them.
Is there anything wrong in this part?
Yes, the DEPENDS clause of ADD_CUSTOM_TARGET() is only for *file*
dependencies, but you use it for *target* dependencies. According
to the documentation of ADD_CUSTOM_TARGET():
Dependencies listed with the DEPENDS argument may reference files
and outputs of custom commands created with add_custom_command()
in the same directory (CMakeLists.txt file).
Use ADD_DEPENDENCIES to add dependencies to or from other targets.
Regards,
Michael
--
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] failing target
On 03/06/2012 02:07 PM, Andrea Crotti wrote:
I opened a thread some time ago about this, and I actually thought it
was a bug in the documentation, because then why everything works
otherwise?
This simple example which I produced
add_custom_target(a
${CMAKE_COMMAND} -E echo a
)
add_custom_target(b
${CMAKE_COMMAND} -E echo b
DEPENDS a
)
does exactly what would be expected, even if there files a or b don't
exist.
So I might suppose that this intra-target dependencies work but not
always,
is that correct?
I tried to substitute the wrong DEPENDS with the add_dependencies and it
seems to work now.
That doesn't explain why it works on Windows and my other Linux box, but
well if that's the correct
way to do it I'll stick with that..
--
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] recognizing shell in use
That is because I have a custom target like
ADD_CUSTOM_TARGET(testc ALL
COMMAND java ${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
)
I want to build test.java only if it has been changed.
Since custom targets are always out-of-date, I wanted to have the
command inside the custom target like
COMMAND if( test.java has not been modified ) then java build/test.java; fi
The syntax of *if* differs between different shells. So I wanted to check
for
the shell first and use the appropriate IF syntax.
Thanks
Ajay
On Mon, Mar 5, 2012 at 11:03 PM, Eric Noulard eric.noul...@gmail.comwrote:
2012/3/6 Ajay Panyala a...@csc.lsu.edu:
Hello,
Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?
May be you can check $ENV{SHELL} ?
Why would you like to do that?
Usually when using CMake one tries to avoid shell/command interpreter
dependency??
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
2012/3/6 Dominik Schmidt do...@tomahawk-player.org:
On Tue, Mar 6, 2012 at 4:05 PM, Eric Noulard eric.noul...@gmail.com wrote:
So the next step would be to configure e.g. CPACK_CROSSPACKAGING and
CPACK_WIN32 in my project config file and try to make GetPrerequisites
work
with them?
That's not what I was thinking about.
May be you could just add something like:
if (CPACK_CROSSPACKAGING)
set(WIN32 @WIN32@)
set(CMAKE_CROSSCOMPILING @CMAKE_CROSSCOMPILING@)
endif(CPACK_CROSSPACKAGING)
So that if CPACK_CROSSPACKAGING is set in your CMakeLists.txt
it will trigger the definition of WIN32 and CMAKE_CROSSCOMPILING in your
configured CPackProjectConfig file.
Neither works. I took a closer look at CPackConfig.cmake in my build
dir and saw
SET(CPACK_SYSTEM_NAME win32) is defined.
(which I didnt define, btw
http://www.vtk.org/Wiki/CMake:CPackConfiguration say it defaults to
CMAKE_SYSTEM_NAME which is Windows in my case tho)
When I tried to print it in GetPrerequisites, it was empty.
So variables defined there aren't available when needed here it seems.
message(FATAL_ERROR CPACK_SYSTEM_NAME is: ${CPACK_SYSTEM_NAME})
CMake Error at
/home/domme/dev/installs/share/cmake-2.8/Modules/GetPrerequisites.cmake:626
(message):
CPACK_SYSTEM_NAME is:
Call Stack (most recent call first):
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:432
(get_prerequisites)
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:612
(get_bundle_keys)
/home/domme/dev/sources/my_client/cmake/modules/DeployQt4.cmake:116
(fixup_bundle)
/home/domme/dev/sources/my_client/win/cmake_install.cmake:43
(FIXUP_QT4_BUNDLE)
This is the interesting part.
This installation part is launched by CPack before packaging.
GetPrerequisites may simply works after that (as far as I understood
your previous e-mail).
Err well. with the rest of my patch applied :-)
So I misunderstood, one of your previous answer
In order to be sure that nothing else is breaking you can try to
[manually] add the missing definition in the CPackConfig.cmake file.
This file is loaded by CPack at CPack-time so that any definitions in
there
will be seen during CPack run.
Went fine.
I have not the rime now to dive into CPack source code in order to check
which context comes with the installation step launched by CPack.
Does the [cross-]DeployQt4 works if you simply do
make install
?
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] failing target
On Tue, Mar 6, 2012 at 10:24 AM, Andrea Crotti
andrea.crott...@gmail.com wrote:
On 03/06/2012 02:07 PM, Andrea Crotti wrote:
I opened a thread some time ago about this, and I actually thought it
was a bug in the documentation, because then why everything works
otherwise?
This simple example which I produced
add_custom_target(a
${CMAKE_COMMAND} -E echo a
)
add_custom_target(b
${CMAKE_COMMAND} -E echo b
DEPENDS a
)
does exactly what would be expected, even if there files a or b don't
exist.
So I might suppose that this intra-target dependencies work but not
always,
is that correct?
I tried to substitute the wrong DEPENDS with the add_dependencies and it
seems to work now.
That doesn't explain why it works on Windows and my other Linux box, but
well if that's the correct
way to do it I'll stick with that..
--
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
The explanation is simple: if you have two targets and they run in
*random* order, then it will be correct 50% of the time... Or
perhaps 100% on one platform and 0% on another. That's likely what you
were seeing when you thought that it worked sometimes.
With the dependencies specified correctly with add_dependencies, you
should now see it work 100% of the time.
--
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-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
On Tue, Mar 6, 2012 at 10:28 AM, Eric Noulard eric.noul...@gmail.com wrote:
2012/3/6 Dominik Schmidt do...@tomahawk-player.org:
On Tue, Mar 6, 2012 at 4:05 PM, Eric Noulard eric.noul...@gmail.com wrote:
So the next step would be to configure e.g. CPACK_CROSSPACKAGING and
CPACK_WIN32 in my project config file and try to make GetPrerequisites
work
with them?
That's not what I was thinking about.
May be you could just add something like:
if (CPACK_CROSSPACKAGING)
set(WIN32 @WIN32@)
set(CMAKE_CROSSCOMPILING @CMAKE_CROSSCOMPILING@)
endif(CPACK_CROSSPACKAGING)
So that if CPACK_CROSSPACKAGING is set in your CMakeLists.txt
it will trigger the definition of WIN32 and CMAKE_CROSSCOMPILING in your
configured CPackProjectConfig file.
Neither works. I took a closer look at CPackConfig.cmake in my build
dir and saw
SET(CPACK_SYSTEM_NAME win32) is defined.
(which I didnt define, btw
http://www.vtk.org/Wiki/CMake:CPackConfiguration say it defaults to
CMAKE_SYSTEM_NAME which is Windows in my case tho)
When I tried to print it in GetPrerequisites, it was empty.
So variables defined there aren't available when needed here it seems.
message(FATAL_ERROR CPACK_SYSTEM_NAME is: ${CPACK_SYSTEM_NAME})
CMake Error at
/home/domme/dev/installs/share/cmake-2.8/Modules/GetPrerequisites.cmake:626
(message):
CPACK_SYSTEM_NAME is:
Call Stack (most recent call first):
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:432
(get_prerequisites)
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:612
(get_bundle_keys)
/home/domme/dev/sources/my_client/cmake/modules/DeployQt4.cmake:116
(fixup_bundle)
/home/domme/dev/sources/my_client/win/cmake_install.cmake:43
(FIXUP_QT4_BUNDLE)
This is the interesting part.
This installation part is launched by CPack before packaging.
GetPrerequisites may simply works after that (as far as I understood
your previous e-mail).
Err well. with the rest of my patch applied :-)
So I misunderstood, one of your previous answer
In order to be sure that nothing else is breaking you can try to
[manually] add the missing definition in the CPackConfig.cmake file.
This file is loaded by CPack at CPack-time so that any definitions in
there
will be seen during CPack run.
Went fine.
I have not the rime now to dive into CPack source code in order to check
which context comes with the installation step launched by CPack.
Does the [cross-]DeployQt4 works if you simply do
make install
?
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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
Just an FYI from the original author of GetPrerequisites here:
cross-packaging was not even considered as we developed it. If it
works at all, it's by happy accident.
I always envisioned packaging as occurring on a host == target platform.
If we want to support cross-packaging for real in CMake/CPack, then we
need some dashboard submissions that build such a beast, and submit
nightly... so that we can monitor for errors when we do make changes
to the source tree.
Thanks, and best of luck here,
David C.
--
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] Ninja + CMake on a dashboard?
2012/2/15 David Cole david.c...@kitware.com: 2012/2/15 Nicolas Desprès nicolas.desp...@gmail.com On Wed, Feb 15, 2012 at 6:09 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 2/15/2012 11:04 AM, Peter Collingbourne wrote: On Wed, Feb 15, 2012 at 10:45:04AM -0500, Bill Hoffman wrote: I note that Kitware has machines set up to run dashboards for the Makefile generator. Is there any reason why some of those machines can't be set up to run double duty as Ninja dashboards, especially given that the work is only required once a day? Thanks, No, we are going to set some up as well. Basically it is a human resource problem. One has to figure out how to build ninja and from where before a dashbaord can be setup. If someone out there is a ninja fan, a dashboard would be appreciated. Bill, If I give you a shell script that can be run by cron and that do the job, could you add it to your build-farm? I know how to do all the bootstrapping stuff. I just have never done any cdash integration/submission but with the documentation you gave me I could probably write it but maybe not test it except it there is a dashboard where I can test. I don't have my own dashboard yet. Feel free to test right on the CMake dashboard itself. Arbitrary submissions that show up in the Nightly section or the Experimental section are ok with us. You don't need your own CDash server... In fact, we want you to send to ours. We are doing better here, but we still need a little improvement before we merge the ninja generator branch into 'master' -- either that, or we need to make a judgment call that says it's ok to have this in master even though it's not completely polished yet. 2 things I'd like to see before we merge: (1) test failures corrected on the Mac Nightly Expected dashboards submitting using the ninja generator (2) reliable dashboard submissions (even if not all tests pass) from a Windows machine using the ninja generator We *could*, if popular demand is high enough, merge it in anyway and call it experimental to start with, or we could get it right all the way before we merge to 'master' and put it out in an official CMake release. Anybody have thoughts on this? Thx, David -- 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] recognizing shell in use
That's the wrong way to go about things. Rather than putting the COMMAND
in the custom target, put it in a add_custom_command() call and make the
custom target DEPENDS on it. Then you let the build system handle the
dependencies. E.g. like this:
find_program(JAVAC_COMPILER javac PATH_SUFFIXES bin ENV JAVA_HOME)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/test.class
COMMAND ${JAVAC_COMPILER} -d ${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
COMMENT Compiling test.java
VERBATIM)
add_custom_target(compile-test-java
DEPENDS ${PROJECT_BINARY_DIR}/test.class)
It looks like test.java is a generated file, so depending on how you
generate it, you also need to set the GENERATED source file property to
TRUE in order for this to work.
HTH
Michael
On 03/06/2012 04:27 PM, Ajay Panyala wrote:
That is because I have a custom target like
ADD_CUSTOM_TARGET(testc ALL
COMMAND java ${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
)
I want to build test.java only if it has been changed.
Since custom targets are always out-of-date, I wanted to have the
command inside the custom target like
COMMAND if( test.java has not been modified ) then java build/test.java; fi
The syntax of *if* differs between different shells. So I wanted to
check for
the shell first and use the appropriate IF syntax.
Thanks
Ajay
On Mon, Mar 5, 2012 at 11:03 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
2012/3/6 Ajay Panyala a...@csc.lsu.edu mailto:a...@csc.lsu.edu:
Hello,
Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?
May be you can check $ENV{SHELL} ?
Why would you like to do that?
Usually when using CMake one tries to avoid shell/command interpreter
dependency??
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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
--
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] transitive linking with separate projects
On 03/06/2012 02:47 PM, Alexander Dahl wrote:
Hei hei,
we faced a build problem with transitive linking of separate projects
where I can't find the right solution on my own. I hope someone can give
me a hint. I prepared a test case with two libraries libfoo and libbar
and an application baz. libfoo is on his own, libbar calls a function
from libfoo and baz calls the function from libbar calling libfoo. So
the dependencies are like this:
baz - libbar - libfoo
baz doesn't need to know of libfoo because it just calls libbar, so I
thought.
Now the projects are separated and both libraries come with cmake
package configuration files. For linking libfoo in libbar I do the
following:
find_package(FOO)
target_link_libraries(BAR_SRC foo-shared)
foo-shared is the target libfoo exports via cmake package
configuration. This works and ldd shows libbar is correctly linked
against libfoo.
Now when compiling baz I more or less do the same:
find_package(BAR)
target_link_libraries(BAZ_SRC bar-shared)
However building baz fails with the following error:
% make
[100%] Building C object src/CMakeFiles/baz.dir/baz.c.o
Linking C executable baz
/usr/bin/ld: cannot find -lfoo-shared
collect2: ld returned 1 exit status
make[2]: *** [src/baz] Fehler 1
make[1]: *** [src/CMakeFiles/baz.dir/all] Fehler 2
make: *** [all] Fehler 2
It seems like cmake tries to link against libfoo here but does not know
anything about it. If I add find_package(FOO) to baz obviously the
target is imported from libfoo cmake package files. The question is, if
I know nothing about the requirements of libbar and want to avoid adding
find_package statements for those requirements to baz, how would I do
this?
I put all the code on GitHub, so if someone maybe could have a look?
https://github.com/LeSpocky/libfoo
https://github.com/LeSpocky/libbar
https://github.com/LeSpocky/baz
Greets
Alex
If you run grep foo -r libbar-install-dir/lib/cmake/bar, you will
see only one line which informs the user of bar-config.cmake that the
bar-shared target has a prerequisite name foo-shared, but there is no
more information. For this reason, it's passed as -lfoo-shared to the
linker. You need to include foo-targets.cmake in bar-config.cmake in
order to make the necessary information available, e.g. by
# libbar/bar-config.cmake.in:
INCLUDE(@FOO_CONFIG@)
get_filename_component(_dir ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(_prefix ${_dir}/../../.. ABSOLUTE)
include(${_dir}/@PROJECT_NAME@-targets.cmake)
set(BAR_INCLUDE_DIRS ${_prefix}/include/@PROJECT_NAME@)
or possibly better:
# libbar/bar-config.cmake.in:
FIND_PACKAGE(FOO PATHS @FOO_DIR@ NO_DEFAULT_PATH)
get_filename_component(_dir ${CMAKE_CURRENT_LIST_FILE} PATH)
get_filename_component(_prefix ${_dir}/../../.. ABSOLUTE)
include(${_dir}/@PROJECT_NAME@-targets.cmake)
set(BAR_INCLUDE_DIRS ${_prefix}/include/@PROJECT_NAME@)
This will make the user of bar-config.cmake include the same foo-
config.cmake and, thus, foo-targets.cmake that bar's CMakeLists.txt
has included, too. See also FIND_PACKAGE()'s NAMES / CONFIGS clauses.
BTW, find modules / config files should provide a *_LIBRARIES variable
even if they use imported targets, e.g.: SET(FOO_LIBRARIES foo-shared)
Regards,
Michael
PS: The baz project on GitHub only contains a README.
--
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-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
2012/3/6 David Cole david.c...@kitware.com: Just an FYI from the original author of GetPrerequisites here: cross-packaging was not even considered as we developed it. If it works at all, it's by happy accident. I always envisioned packaging as occurring on a host == target platform. Thus my initial remark: Cross-compiling is one thing, cross packaging is another one (which may be difficult or impossible in the general case). If we want to support cross-packaging for real in CMake/CPack, then we need some dashboard submissions that build such a beast, and submit nightly... so that we can monitor for errors when we do make changes to the source tree. Thanks, and best of luck here, I just wanted to help Dominik to go as far as I can but I won't certainly have time to create test cases nor dashboard for that. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Ninja + CMake on a dashboard?
2012/3/6 David Cole david.c...@kitware.com: 2012/2/15 David Cole david.c...@kitware.com: 2012/2/15 Nicolas Desprès nicolas.desp...@gmail.com On Wed, Feb 15, 2012 at 6:09 PM, Bill Hoffman bill.hoff...@kitware.com wrote: On 2/15/2012 11:04 AM, Peter Collingbourne wrote: On Wed, Feb 15, 2012 at 10:45:04AM -0500, Bill Hoffman wrote: I note that Kitware has machines set up to run dashboards for the Makefile generator. Is there any reason why some of those machines can't be set up to run double duty as Ninja dashboards, especially given that the work is only required once a day? Thanks, No, we are going to set some up as well. Basically it is a human resource problem. One has to figure out how to build ninja and from where before a dashbaord can be setup. If someone out there is a ninja fan, a dashboard would be appreciated. Bill, If I give you a shell script that can be run by cron and that do the job, could you add it to your build-farm? I know how to do all the bootstrapping stuff. I just have never done any cdash integration/submission but with the documentation you gave me I could probably write it but maybe not test it except it there is a dashboard where I can test. I don't have my own dashboard yet. Feel free to test right on the CMake dashboard itself. Arbitrary submissions that show up in the Nightly section or the Experimental section are ok with us. You don't need your own CDash server... In fact, we want you to send to ours. We are doing better here, but we still need a little improvement before we merge the ninja generator branch into 'master' -- either that, or we need to make a judgment call that says it's ok to have this in master even though it's not completely polished yet. 2 things I'd like to see before we merge: (1) test failures corrected on the Mac Nightly Expected dashboards submitting using the ninja generator I am sorry but I did not manage to find the time to tackle them. Unfortunately, I am very busy at the moment. (2) reliable dashboard submissions (even if not all tests pass) from a Windows machine using the ninja generator We *could*, if popular demand is high enough, merge it in anyway and call it experimental to start with, or we could get it right all the way before we merge to 'master' and put it out in an official CMake release. Anybody have thoughts on this? +1 for publishing I think it will boost up the development, bringing more people to work on it. Cheers, -- Nicolas Desprès -- 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-developers] CPack: GetPrerequisites: cross-compiling from Linux to Windows
Hi
On Tue, Mar 6, 2012 at 4:28 PM, Eric Noulard eric.noul...@gmail.com wrote:
This is the interesting part.
This installation part is launched by CPack before packaging.
So I misunderstood, one of your previous answer
In order to be sure that nothing else is breaking you can try to
[manually] add the missing definition in the CPackConfig.cmake file.
This file is loaded by CPack at CPack-time so that any definitions in
there
will be seen during CPack run.
Went fine.
I have not the rime now to dive into CPack source code in order to check
which context comes with the installation step launched by CPack.
Does the [cross-]DeployQt4 works if you simply do
make install
?
No.
message(FATAL_ERROR CPACK_SYSTEM_NAME is : ${CPACK_SYSTEM_NAME}
CMAKE_SYSTEM_NAME: ${CMAKE_SYSTEM_NAME} CMAKE_CROSSCOMPILING:
${CMAKE_CROSSCOMPILING} )
CMake Error at
/home/domme/dev/installs/share/cmake-2.8/Modules/GetPrerequisites.cmake:626
(message):
CPACK_SYSTEM_NAME is : CMAKE_SYSTEM_NAME: CMAKE_CROSSCOMPILING:
Call Stack (most recent call first):
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:432
(get_prerequisites)
/home/domme/dev/installs/share/cmake-2.8/Modules/BundleUtilities.cmake:612
(get_bundle_keys)
/home/domme/dev/sources/zokyo_client/cmake/modules/DeployQt4.cmake:116
(fixup_bundle)
cmake_install.cmake:43 (FIXUP_QT4_BUNDLE)
It's the same for cpack --verbose or make install.
Just an FYI from the original author of GetPrerequisites here:
cross-packaging was not even considered as we developed it. If it
works at all, it's by happy accident.
The only unsolved problem so far is, I can't set any variable at
cpack-install time. So I cant even manually enforce gp_tool = objdump.
Would I need to write it to cmake_install.cmake somehow?
I always envisioned packaging as occurring on a host == target platform.
NSIS does a pretty good cross-job :)
If we want to support cross-packaging for real in CMake/CPack, then we
need some dashboard submissions that build such a beast, and submit
nightly... so that we can monitor for errors when we do make changes
to the source tree.
To me it looks like it only needs a pretty minor change at least on
GetPrerequisites side.
Thanks, and best of luck here,
David C.
Thanks,
Dominik
--
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] failing target
On 03/06/2012 03:29 PM, David Cole wrote: On Tue, Mar 6, 2012 at 10:24 AM, Andrea Crotti The explanation is simple: if you have two targets and they run in *random* order, then it will be correct 50% of the time... Or perhaps 100% on one platform and 0% on another. That's likely what you were seeing when you thought that it worked sometimes. With the dependencies specified correctly with add_dependencies, you should now see it work 100% of the time. Very good thanks, now I'm satisfied ;) the problem was appearing in fact when I was trying to run in parallel, which explains everything.. -- 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] Ninja + CMake on a dashboard?
On 3/6/2012 10:52 AM, Nicolas Desprès wrote: +1 for publishing I think it will boost up the development, bringing more people to work on it. It would be nice to fix the stuff that we know about, as people will of course start reporting bugs as soon as they find them. I guess as long as we note the limitations. Along the lines of the Windows support, what is the status? I don't see ninja support in the next branch of cmake. Just built it and there is no ninja generator yet. I would be happy to setup an experimental ninja windows generator dashboard for windows. However, we need the support to be in next. -Bill -- 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] Ninja + CMake on a dashboard?
On Tue, Mar 06, 2012 at 10:41:19AM -0500, David Cole wrote: 2 things I'd like to see before we merge: (1) test failures corrected on the Mac Nightly Expected dashboards submitting using the ninja generator (2) reliable dashboard submissions (even if not all tests pass) from a Windows machine using the ninja generator We *could*, if popular demand is high enough, merge it in anyway and call it experimental to start with, or we could get it right all the way before we merge to 'master' and put it out in an official CMake release. +1 on merging soon. The generator will be disabled on Windows by default so there is no risk of Windows users accidentally trying to use it. Most of the test failures on the Mac relate to Mac specific targets (frameworks/bundles/apps) which I think most portable applications can survive without, and in any case we can document this missing feature in a release note or perhaps have the Ninja generator print an error if it sees one of these targets. Thanks, -- Peter -- 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] find_package(Subversion) fails when run by an automated Jenkins build
Switching the Jenkins node services to run under the correct build service AD
domain account fixed the problem...I think. I did the switch to fix some other
unrelated problem, then went back to address this one, and found that it had
fixed itself.
Before fixing itself, the Jenkins node services were running under the built-in
system account.
Thanks very much for the feedback!
-Original Message-
From: Eric Noulard [mailto:eric.noul...@gmail.com]
Sent: 29 February 2012 18:32
To: Massaro Alessio
Cc: cmake@cmake.org
Subject: Re: [CMake] find_package(Subversion) fails when run by an automated
Jenkins build
2012/2/29 Massaro Alessio alessio.mass...@mediobanca.co.uk:
Hi there,
Awkward behaviour:
My CMakeLists.txt do a find_package(Subversion)
Now, I have a Jenkins build server running under domain user XYZ
The Jenkins CMake plugin tells me it's trying to do the following:
c:\Program Files\CMake 2.8\bin\cmake.exe -G Visual Studio
9 2008
-DCMAKE_BUILD_TYPE=Release
D:\path\to\where\jenkins\puts\mysource
And fails with
-- Could NOT find Subversion (missing:
Subversion_SVN_EXECUTABLE)
But if I logon to that very same server with that very same domain
user, check-out the code from svn elsewhere on the server disk and run
the above command (adjusting for the different path to the source),
then the find_package will work just fine.
Does anyone have a clue on what the problem might be?
What might be causing the difference in behaviour?
May be the path is set to a different value in the Jenkins context.
You could try to make your CMakeLists.txt display the content of the PATH
variable with something like;
MESSAGE(PATH=$ENV{PATH})
that way you'll see if something is different
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] MSVC_VERSION for VC11?
I actually need to check the compiler version for ABI compatibility reasons. I download my third party libraries via CMake script and I check the current compiler version so I know which DLLs to download :P Unfortunately C++ name mangling is not standardized so this is necessary. Also it is quite possible to have the pimpl pattern in my code base, designed in such a way that different CPP files are included in my targets depending on compiler version. It's a way to abstract away platform-specific and compiler-specific implementation details (Perhaps I use MSVC-specific extensions in my pimpl class, or maybe I do some inline assembler to overcome a specific optimization failure or inefficiency in older versions of MSVC). Need more examples? :P - Robert Dailey On Mon, Mar 5, 2012 at 3:25 PM, Eric Noulard eric.noul...@gmail.com wrote: 2012/3/5 Robert Dailey rcdai...@gmail.com: The docs aren't updated to reflect this so I just wanted to make sure. Patch for documentation may be accepted as well :-] I didn't have time to run through the source code (you Linux people and your fancy 'git grep' commands :P ) You Windows people and your need to check compiler version before trying to compile a portable piece of code :P !! -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] Updated: CMake 2.8.7-1
Never mind, I manually installed 2.8.6. I uninstalled 2.8.6 and all is well. -Original Message- From: Keith Gardner Sent: Tuesday, March 06, 2012 11:43 AM To: 'Bill Hoffman'; cygwin-annou...@cygwin.com; cm...@public.kitware.com Subject: RE: [CMake] Updated: CMake 2.8.7-1 I just did an update of CMake on Cygwin and found a weird inconstancy. the Cygwin installer calls the version 2.8.7-1 but if you run cmake -version you get 2.8.6. Which is correct? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Tuesday, March 06, 2012 7:54 AM To: cygwin-annou...@cygwin.com; cm...@public.kitware.com Subject: [CMake] Updated: CMake 2.8.7-1 CMake 2.8.7-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - improved Eclipse support - incremental improvements to the AUTOMOC feature added in the previous release - more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512) - file(...) and string(...) command additions for computing hash values - added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command - new module: DeployQt4 - and, as always, various minor bug fixes Similar to the previous release, we do not have pre-built binaries for the SunOS anymore. However, now we have two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. There was a bit of a network connectivity snag in building the binaries for the AIX platform today... Because of this, the tarballs for AIX will not be available until sometime next week. Following is the complete list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Thanks for using CMake! -Bill Changes in CMake 2.8.7 (since 2.8.7-rc2) None Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1) Alex Neundorf (5): automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE automoc: improved warning message in relaxed mode Remove trailing whitespace Add comment about one more problem of the C depency scanner. fix #12262: dependency scanning for ASM files Bill Hoffman (1): Fix the case where cmake --build failed with two project cmds in one file. Brad King (11): KWSys: Correctly handle empty environment variables FortranCInterface: Work around mingw32-make trouble with parens Xcode: Create separate rerun dependencies for subprojects (#12616) Fix Intel Fortran .vfproj files for VS 10 HP: Drive shared library linking with compiler front end Follow all dependencies of shared library private dependencies Do not link private dependent shared libraries on OS X 10.4 Avoid clobbering variable 'OUTPUT' in compiler tests (#12628) Fix and simplify Fortran test compiler compatibility check CTest: Recognize Intel errors without space before colon (#12627) Windows-GNU: Remove extra quotes in GNUtoMS rule variable David Cole (4): Release: Increase timeout for slow-testing cygwin build Modules: Use windres as rc compiler base name for cross-compiles (#12480) Tests: Only really run MFC test if we can build MFC apps (#11213) FindBoost: Quote possibly empty string argument (#12273) Eric NOULARD (1): CPackRPM fix #0012608 and unoticed related bug Johan Fänge (1): CMake: Fix progress reporting for custom targets (#12441) Mike McQuaid (2): Unset configurations variable when no build type. Improve component support and output indentation. Raphael Kubo da Costa (2): Remove the apparently outdated README in Source/QtDialog. QtDialog: Set Ctrl+Q as the shortcut for quitting the program. Tim Gallagher (2): FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624) FindLAPACK: List thread libs to avoid link errors (#12625) Valat Sébastien (1): CTest: Do not get CDash version without drop site (#12618) Changes in CMake 2.8.7-rc1 (since 2.8.6) Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (60): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders if not
Re: [CMake] Updated: CMake 2.8.7-1
I just did an update of CMake on Cygwin and found a weird inconstancy. the Cygwin installer calls the version 2.8.7-1 but if you run cmake -version you get 2.8.6. Which is correct? -Original Message- From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Bill Hoffman Sent: Tuesday, March 06, 2012 7:54 AM To: cygwin-annou...@cygwin.com; cm...@public.kitware.com Subject: [CMake] Updated: CMake 2.8.7-1 CMake 2.8.7-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - improved Eclipse support - incremental improvements to the AUTOMOC feature added in the previous release - more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512) - file(...) and string(...) command additions for computing hash values - added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command - new module: DeployQt4 - and, as always, various minor bug fixes Similar to the previous release, we do not have pre-built binaries for the SunOS anymore. However, now we have two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. There was a bit of a network connectivity snag in building the binaries for the AIX platform today... Because of this, the tarballs for AIX will not be available until sometime next week. Following is the complete list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Thanks for using CMake! -Bill Changes in CMake 2.8.7 (since 2.8.7-rc2) None Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1) Alex Neundorf (5): automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE automoc: improved warning message in relaxed mode Remove trailing whitespace Add comment about one more problem of the C depency scanner. fix #12262: dependency scanning for ASM files Bill Hoffman (1): Fix the case where cmake --build failed with two project cmds in one file. Brad King (11): KWSys: Correctly handle empty environment variables FortranCInterface: Work around mingw32-make trouble with parens Xcode: Create separate rerun dependencies for subprojects (#12616) Fix Intel Fortran .vfproj files for VS 10 HP: Drive shared library linking with compiler front end Follow all dependencies of shared library private dependencies Do not link private dependent shared libraries on OS X 10.4 Avoid clobbering variable 'OUTPUT' in compiler tests (#12628) Fix and simplify Fortran test compiler compatibility check CTest: Recognize Intel errors without space before colon (#12627) Windows-GNU: Remove extra quotes in GNUtoMS rule variable David Cole (4): Release: Increase timeout for slow-testing cygwin build Modules: Use windres as rc compiler base name for cross-compiles (#12480) Tests: Only really run MFC test if we can build MFC apps (#11213) FindBoost: Quote possibly empty string argument (#12273) Eric NOULARD (1): CPackRPM fix #0012608 and unoticed related bug Johan Fänge (1): CMake: Fix progress reporting for custom targets (#12441) Mike McQuaid (2): Unset configurations variable when no build type. Improve component support and output indentation. Raphael Kubo da Costa (2): Remove the apparently outdated README in Source/QtDialog. QtDialog: Set Ctrl+Q as the shortcut for quitting the program. Tim Gallagher (2): FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624) FindLAPACK: List thread libs to avoid link errors (#12625) Valat Sébastien (1): CTest: Do not get CDash version without drop site (#12618) Changes in CMake 2.8.7-rc1 (since 2.8.6) Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (60): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders if not supported Eclipse: better message when Eclipse version could not be determined automoc:run moc on the header if the source file contains include foo.moc Add copyright notices automoc: always run moc on the cpp file if there is a foo.moc included Eclipse:
Re: [CMake] Updated: CMake 2.8.7-1
Could you list the mirror URLs for me that were updated? I'm trying a few that are listed in the setup.exe for cygwin but I'm not seeing the new version. Still shows 2.8.4 for the mirrors I tried. - Robert Dailey On Tue, Mar 6, 2012 at 7:53 AM, Bill Hoffman bill.hoff...@kitware.comwrote: CMake 2.8.7-1 is now available on Cygwin mirrors. Some of the notable changes in this release are: - improved Eclipse support - incremental improvements to the AUTOMOC feature added in the previous release - more cryptographic hash implementations (SHA1, SHA224, SHA256, SHA384, SHA512) - file(...) and string(...) command additions for computing hash values - added LINK_PUBLIC and LINK_PRIVATE options to target_link_libraries command - new module: DeployQt4 - and, as always, various minor bug fixes Similar to the previous release, we do not have pre-built binaries for the SunOS anymore. However, now we have two sets of installers for the Mac. The Darwin versions are for Mac OSX 10.4 and later, and are ppc;i386 universal binaries. The Darwin64 versions are for 10.6 and later, and are x86_64;i386 universal binaries. There was a bit of a network connectivity snag in building the binaries for the AIX platform today... Because of this, the tarballs for AIX will not be available until sometime next week. Following is the complete list of changes in this release. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. Thanks for using CMake! -Bill Changes in CMake 2.8.7 (since 2.8.7-rc2) --**-- None Changes in CMake 2.8.7-rc2 (since 2.8.7-rc1) --**-- Alex Neundorf (5): automoc: default to strict mode, use CMAKE_AUTOMOC_RELAXED_MODE automoc: improved warning message in relaxed mode Remove trailing whitespace Add comment about one more problem of the C depency scanner. fix #12262: dependency scanning for ASM files Bill Hoffman (1): Fix the case where cmake --build failed with two project cmds in one file. Brad King (11): KWSys: Correctly handle empty environment variables FortranCInterface: Work around mingw32-make trouble with parens Xcode: Create separate rerun dependencies for subprojects (#12616) Fix Intel Fortran .vfproj files for VS 10 HP: Drive shared library linking with compiler front end Follow all dependencies of shared library private dependencies Do not link private dependent shared libraries on OS X 10.4 Avoid clobbering variable 'OUTPUT' in compiler tests (#12628) Fix and simplify Fortran test compiler compatibility check CTest: Recognize Intel errors without space before colon (#12627) Windows-GNU: Remove extra quotes in GNUtoMS rule variable David Cole (4): Release: Increase timeout for slow-testing cygwin build Modules: Use windres as rc compiler base name for cross-compiles (#12480) Tests: Only really run MFC test if we can build MFC apps (#11213) FindBoost: Quote possibly empty string argument (#12273) Eric NOULARD (1): CPackRPM fix #0012608 and unoticed related bug Johan Fänge (1): CMake: Fix progress reporting for custom targets (#12441) Mike McQuaid (2): Unset configurations variable when no build type. Improve component support and output indentation. Raphael Kubo da Costa (2): Remove the apparently outdated README in Source/QtDialog. QtDialog: Set Ctrl+Q as the shortcut for quitting the program. Tim Gallagher (2): FindLAPACK: Correct CMAKE_FIND_LIBRARY_SUFFIXES spelling (#12624) FindLAPACK: List thread libs to avoid link errors (#12625) Valat Sébastien (1): CTest: Do not get CDash version without drop site (#12618) Changes in CMake 2.8.7-rc1 (since 2.8.6) --**-- Aaron Ten Clay (1): VS: Add support for three new project properties (#12586) Alex Neundorf (60): fix #12392: handle CMAKE_CXX_COMPILER_ARG1 for Eclipse projects fix #12262: use the C dependency scanner also for ASM files fix #12465: detect the masm compiler ID (MSVC) Silence make on OpenBSD in FindPackageModeTest(#12508) Remove trailing whitespace Find Ruby on OpenBSD when installed from ports (#12507) Eclipse generator: detect Eclipse version Detect whether the current Eclipse version supports VirtualFolders Eclipse: don't create VirtualFolders if not supported Eclipse: better message when Eclipse version could not be determined automoc:run moc on the header if the source file contains include foo.moc Add copyright notices automoc: always run moc on the cpp file if there is a foo.moc included Eclipse: add virtual folder for each target Eclipse: move code for generating links to projects into separate function Eclipse: move code
Re: [CMake] Ninja + CMake on a dashboard?
On 06.03.12 17:10:41, Peter Collingbourne wrote:
On Tue, Mar 06, 2012 at 10:41:19AM -0500, David Cole wrote:
2 things I'd like to see before we merge:
(1) test failures corrected on the Mac Nightly Expected dashboards
submitting using the ninja generator
(2) reliable dashboard submissions (even if not all tests pass) from a
Windows machine using the ninja generator
We *could*, if popular demand is high enough, merge it in anyway and
call it experimental to start with, or we could get it right all the
way before we merge to 'master' and put it out in an official CMake
release.
+1 on merging soon. The generator will be disabled on Windows by
default so there is no risk of Windows users accidentally trying to
use it. Most of the test failures on the Mac relate to Mac specific
targets (frameworks/bundles/apps) which I think most portable
applications can survive without
You have any evidence for that? Usually cross-platform doesn't mean
ignore the platform conventions, but simply abstract away from that.
In that sense I'd expect cross-platform apps to have something like
add_executable(foo WIN32 MACOSX_BUNDLE ${SRCS})
since cmake will simply ignore the windows/macosx specific flags on
platforms that they don't apply on.
For a CMake release I'd say that the generator should fully work on all
platforms it is enabled on. If there are things that are not supported
on a platform, disable it there.
Andreas
--
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] recognizing shell in use
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/test.class
COMMAND ${JAVAC_COMPILER} -d ${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
COMMENT Compiling test.java
VERBATIM)
add_custom_target(compile-test-java
DEPENDS ${PROJECT_BINARY_DIR}/test.class)
I tried this. It builds as expected initially. But when I change test.java
and run
make, it is not re-compiled.
It looks like test.java is a generated file, so depending on how you
generate it, you also need to set the GENERATED source file property to
TRUE in order for this to work.
test.java is not a generated file. I am modifying it manually and trying to
build.
Thanks
Ajay
On Tue, Mar 6, 2012 at 7:43 AM, Michael Wild them...@gmail.com wrote:
That's the wrong way to go about things. Rather than putting the COMMAND
in the custom target, put it in a add_custom_command() call and make the
custom target DEPENDS on it. Then you let the build system handle the
dependencies. E.g. like this:
find_program(JAVAC_COMPILER javac PATH_SUFFIXES bin ENV JAVA_HOME)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/test.class
COMMAND ${JAVAC_COMPILER} -d ${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
COMMENT Compiling test.java
VERBATIM)
add_custom_target(compile-test-java
DEPENDS ${PROJECT_BINARY_DIR}/test.class)
It looks like test.java is a generated file, so depending on how you
generate it, you also need to set the GENERATED source file property to
TRUE in order for this to work.
HTH
Michael
On 03/06/2012 04:27 PM, Ajay Panyala wrote:
That is because I have a custom target like
ADD_CUSTOM_TARGET(testc ALL
COMMAND java ${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
)
I want to build test.java only if it has been changed.
Since custom targets are always out-of-date, I wanted to have the
command inside the custom target like
COMMAND if( test.java has not been modified ) then java build/test.java;
fi
The syntax of *if* differs between different shells. So I wanted to
check for
the shell first and use the appropriate IF syntax.
Thanks
Ajay
On Mon, Mar 5, 2012 at 11:03 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
2012/3/6 Ajay Panyala a...@csc.lsu.edu mailto:a...@csc.lsu.edu:
Hello,
Is there anyway that cmake could figure out the shell (bash,csh,..)
that is being use when cmake is invoked on the command line ?
May be you can check $ENV{SHELL} ?
Why would you like to do that?
Usually when using CMake one tries to avoid shell/command interpreter
dependency??
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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
--
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
--
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] Code and API review request for Qt5 CMake files
On Monday 05 March 2012, Stephen Kelly wrote: Rolf Eike Beer wrote: Michael Hertling wrote: My main conclusion from the above-noted mess among CMake's current component-aware find modules is that we urgently need a convention how such modules and config files are intended to work. Hopefully, we can take a step forward; Qt5's advent is a good opportunity. Yes, please! And a good start would be cleaning up FindwxWidgets.cmake and porting it to use FPHSA so we get REQUIRED handling for free. Has this resulted in anything concrete being raised on the -developers list? I'm about to write a patch which makes it possible to set the _FOUND variable also in Config.cmake file, if something failed. Alex -- 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] Ninja + CMake on a dashboard?
On Tue, Mar 06, 2012 at 07:09:03PM +0100, Andreas Pakulat wrote:
On 06.03.12 17:10:41, Peter Collingbourne wrote:
On Tue, Mar 06, 2012 at 10:41:19AM -0500, David Cole wrote:
2 things I'd like to see before we merge:
(1) test failures corrected on the Mac Nightly Expected dashboards
submitting using the ninja generator
(2) reliable dashboard submissions (even if not all tests pass) from a
Windows machine using the ninja generator
We *could*, if popular demand is high enough, merge it in anyway and
call it experimental to start with, or we could get it right all the
way before we merge to 'master' and put it out in an official CMake
release.
+1 on merging soon. The generator will be disabled on Windows by
default so there is no risk of Windows users accidentally trying to
use it. Most of the test failures on the Mac relate to Mac specific
targets (frameworks/bundles/apps) which I think most portable
applications can survive without
You have any evidence for that? Usually cross-platform doesn't mean
ignore the platform conventions, but simply abstract away from that.
In that sense I'd expect cross-platform apps to have something like
add_executable(foo WIN32 MACOSX_BUNDLE ${SRCS})
since cmake will simply ignore the windows/macosx specific flags on
platforms that they don't apply on.
For a CMake release I'd say that the generator should fully work on all
platforms it is enabled on. If there are things that are not supported
on a platform, disable it there.
Obviously things won't work perfectly (if at all) for things like GUI
applications or bundles. But there are a number of command line tools
(such as LLVM/Clang) which do not use any of the OS X packaging stuff.
I myself have used the generator to build LLVM/Clang on a Mac and
I know a few people who do that regularly. I don't think we should
exclude an entire platform just because things won't work for a subset
of users, especially when it is easy to detect such cases and we can
warn/error out.
Thanks,
--
Peter
--
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] Ninja + CMake on a dashboard?
On 3/6/2012 1:47 PM, Peter Collingbourne wrote: Obviously things won't work perfectly (if at all) for things like GUI applications or bundles. But there are a number of command line tools (such as LLVM/Clang) which do not use any of the OS X packaging stuff. I myself have used the generator to build LLVM/Clang on a Mac and I know a few people who do that regularly. I don't think we should exclude an entire platform just because things won't work for a subset of users, especially when it is easy to detect such cases and we can warn/error out. GUI on Mac is a big part of Mac users. This means no Qt application will work. It is a pretty big hole for that platform... -Bill -- 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] Ninja + CMake on a dashboard?
On 06.03.12 18:47:05, Peter Collingbourne wrote:
On Tue, Mar 06, 2012 at 07:09:03PM +0100, Andreas Pakulat wrote:
On 06.03.12 17:10:41, Peter Collingbourne wrote:
On Tue, Mar 06, 2012 at 10:41:19AM -0500, David Cole wrote:
2 things I'd like to see before we merge:
(1) test failures corrected on the Mac Nightly Expected dashboards
submitting using the ninja generator
(2) reliable dashboard submissions (even if not all tests pass) from a
Windows machine using the ninja generator
We *could*, if popular demand is high enough, merge it in anyway and
call it experimental to start with, or we could get it right all the
way before we merge to 'master' and put it out in an official CMake
release.
+1 on merging soon. The generator will be disabled on Windows by
default so there is no risk of Windows users accidentally trying to
use it. Most of the test failures on the Mac relate to Mac specific
targets (frameworks/bundles/apps) which I think most portable
applications can survive without
You have any evidence for that? Usually cross-platform doesn't mean
ignore the platform conventions, but simply abstract away from that.
In that sense I'd expect cross-platform apps to have something like
add_executable(foo WIN32 MACOSX_BUNDLE ${SRCS})
since cmake will simply ignore the windows/macosx specific flags on
platforms that they don't apply on.
For a CMake release I'd say that the generator should fully work on all
platforms it is enabled on. If there are things that are not supported
on a platform, disable it there.
Obviously things won't work perfectly (if at all) for things like GUI
applications or bundles. But there are a number of command line tools
(such as LLVM/Clang) which do not use any of the OS X packaging stuff.
As Bill said, allowing more-or-less only commandline apps leaves out
lots of things. Also I don't think llvm/clang is a good reference here
since it has few if any external dependencies which may come as
frameworks eventually. By excluding frameworks and app bundles you're
basically limiting the generator on that platform to at most 1/3 of the
currently available projects that build on it - probably much less.
Personally I wouldn't accept this from a stable release of a
cross-platform buildtool.
Andreas
--
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] recognizing shell in use
On Tue, Mar 6, 2012 at 1:22 PM, Ajay Panyala a...@csc.lsu.edu wrote:
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/test.class
COMMAND ${JAVAC_COMPILER} -d ${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
COMMENT Compiling test.java
VERBATIM)
add_custom_target(compile-test-java
DEPENDS ${PROJECT_BINARY_DIR}/test.class)
I tried this. It builds as expected initially. But when I change test.java
and run
make, it is not re-compiled.
It looks like test.java is a generated file, so depending on how you
generate it, you also need to set the GENERATED source file property to
TRUE in order for this to work.
test.java is not a generated file. I am modifying it manually and trying to
build.
Thanks
Ajay
On Tue, Mar 6, 2012 at 7:43 AM, Michael Wild them...@gmail.com wrote:
That's the wrong way to go about things. Rather than putting the COMMAND
in the custom target, put it in a add_custom_command() call and make the
custom target DEPENDS on it. Then you let the build system handle the
dependencies. E.g. like this:
find_program(JAVAC_COMPILER javac PATH_SUFFIXES bin ENV JAVA_HOME)
add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/test.class
COMMAND ${JAVAC_COMPILER} -d ${PROJECT_BINARY_DIR}
${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
COMMENT Compiling test.java
VERBATIM)
add_custom_target(compile-test-java
DEPENDS ${PROJECT_BINARY_DIR}/test.class)
It looks like test.java is a generated file, so depending on how you
generate it, you also need to set the GENERATED source file property to
TRUE in order for this to work.
HTH
Michael
On 03/06/2012 04:27 PM, Ajay Panyala wrote:
That is because I have a custom target like
ADD_CUSTOM_TARGET(testc ALL
COMMAND java ${PROJECT_BINARY_DIR}/test.java
DEPENDS ${PROJECT_BINARY_DIR}/test.java
)
I want to build test.java only if it has been changed.
Since custom targets are always out-of-date, I wanted to have the
command inside the custom target like
COMMAND if( test.java has not been modified ) then java build/test.java;
fi
The syntax of *if* differs between different shells. So I wanted to
check for
the shell first and use the appropriate IF syntax.
Thanks
Ajay
On Mon, Mar 5, 2012 at 11:03 PM, Eric Noulard eric.noul...@gmail.com
mailto:eric.noul...@gmail.com wrote:
2012/3/6 Ajay Panyala a...@csc.lsu.edu mailto:a...@csc.lsu.edu:
Hello,
Is there anyway that cmake could figure out the shell
(bash,csh,..)
that is being use when cmake is invoked on the command line ?
May be you can check $ENV{SHELL} ?
Why would you like to do that?
Usually when using CMake one tries to avoid shell/command
interpreter
dependency??
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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
--
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
--
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
Is CMAKE_CURRENT_BINARY_DIR the same as PROJECT_BINARY_DIR?
You have one listed as the OUTPUT file and the other listed as the
location of the DEPENDS file...
--
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] Ninja + CMake on a dashboard?
On Mar 6, 2012, at 2:41 PM, Andreas Pakulat wrote:
On 06.03.12 18:47:05, Peter Collingbourne wrote:
On Tue, Mar 06, 2012 at 07:09:03PM +0100, Andreas Pakulat wrote:
On 06.03.12 17:10:41, Peter Collingbourne wrote:
On Tue, Mar 06, 2012 at 10:41:19AM -0500, David Cole wrote:
2 things I'd like to see before we merge:
(1) test failures corrected on the Mac Nightly Expected dashboards
submitting using the ninja generator
(2) reliable dashboard submissions (even if not all tests pass) from a
Windows machine using the ninja generator
We *could*, if popular demand is high enough, merge it in anyway and
call it experimental to start with, or we could get it right all the
way before we merge to 'master' and put it out in an official CMake
release.
+1 on merging soon. The generator will be disabled on Windows by
default so there is no risk of Windows users accidentally trying to
use it. Most of the test failures on the Mac relate to Mac specific
targets (frameworks/bundles/apps) which I think most portable
applications can survive without
You have any evidence for that? Usually cross-platform doesn't mean
ignore the platform conventions, but simply abstract away from that.
In that sense I'd expect cross-platform apps to have something like
add_executable(foo WIN32 MACOSX_BUNDLE ${SRCS})
since cmake will simply ignore the windows/macosx specific flags on
platforms that they don't apply on.
For a CMake release I'd say that the generator should fully work on all
platforms it is enabled on. If there are things that are not supported
on a platform, disable it there.
Obviously things won't work perfectly (if at all) for things like GUI
applications or bundles. But there are a number of command line tools
(such as LLVM/Clang) which do not use any of the OS X packaging stuff.
As Bill said, allowing more-or-less only commandline apps leaves out
lots of things. Also I don't think llvm/clang is a good reference here
since it has few if any external dependencies which may come as
frameworks eventually. By excluding frameworks and app bundles you're
basically limiting the generator on that platform to at most 1/3 of the
currently available projects that build on it - probably much less.
Personally I wouldn't accept this from a stable release of a
cross-platform buildtool.
Andreas
As an OS X developer using Qt to develop GUIs ninja would leave me out in the
cold. And more over if I had not been keeping on on this thread then I may have
actually tried Ninja, blew time trying to figure out why my GUI apps are not
building and then possibly finally finding out that Ninja does not support .app
and .framework outputs. I would limit ninja to the build platforms that do not
have these issues which would mainly be the *nix platforms.
___
Mike JacksonPrincipal Software Engineer
BlueQuartz SoftwareDayton, Ohio
mike.jack...@bluequartz.net www.bluequartz.net
--
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] Impossible to link SDLmain and LibXml2
Hi, I have a problem with cmake not to compile but to link my .exe. I use SDL, OpenGL, FMOD, LibXml2 and a personal library. But when I try to compile my program LibXml2 and SDLmain are not include into the command line to link my .exe. Enclosed my CMakeList.txt and CMakeCache.txt and here the line for the linker into build.make: Output/shootspace.exe: C:/MinGW/lib/libSDL.dll.a Output/shootspace.exe: C:/MinGW/lib/libfmodex.a Output/shootspace.exe: CMakeFiles/shootspace.dir/build.make Output/shootspace.exe: CMakeFiles/shootspace.dir/objects1.rsp @$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --red --bold Linking CXX executable Output/shootspace.exe /c/Program Files (x86)/CMake 2.8/bin/cmake.exe -E remove -f CMakeFiles/shootspace.dir/objects.a /C/MinGW/bin/ar.exe cr CMakeFiles/shootspace.dir/objects.a @CMakeFiles/shootspace.dir/objects1.rsp /C/MinGW/bin/g++.exe -Wl,--whole-archive CMakeFiles/shootspace.dir/objects.a -Wl,--no-whole-archive -o Output/shootspace.exe -Wl,--out-implib,Output/libshootspace.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -Lsource/lib/gtl/lib/mingw -lmingw32 /C/MinGW/lib/libSDL.dll.a -lpthread -lglu32 -lopengl32 /C/MinGW/lib/libfmodex.a -lgtl -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 As you can see, LibXml2 library and SDLmain library are found in CMakeCache.txt but not include in build.make because lxml2 and lSDLmain are missing. Why ? I do something wrong in my CMakeList.txt ? Thanks in advance for your help. Cheers. --- Julien Plu Etudiant en 2ème année de Master Ingénierie en Intelligence Artificielle à lUniversité Montpellier 2. Mes projets Web sémantique : http://data.lirmm.fr Page personnelle : http://jplu.developpez.com Responsable de la rubrique Web sémantique http://web-semantique.developpez.com/ de Developpez.com. Fichier FOAF (version RDF) : http://jplu.developpez.com/julien Fichier FOAF (version RDFa) : http://jplu.developpez.com/julien.html Adresse mail personnelle : julien@redaction-developpez.com Adresse mail universitaire : julien@etud.univ-montp2.fr # This is the CMakeCache file. # For build in directory: c:/Users/snake/workspaceCpp/ShootSpace # It was generated by CMake: c:/Program Files (x86)/CMake 2.8/bin/cmake.exe # You can edit this file to change values found and used by cmake. # If you do not want to change any of the values, simply exit the editor. # If you do want to change a value, simply edit, save, and exit the editor. # The syntax for the file is as follows: # KEY:TYPE=VALUE # KEY is the name of a variable in the cache. # TYPE is a hint to GUI's for the type of VALUE, DO NOT EDIT TYPE!. # VALUE is the current value for the KEY. # EXTERNAL cache entries //Path to a program. CMAKE_AR:FILEPATH=C:/MinGW/bin/ar.exe //Choose the type of build, options are: None(CMAKE_CXX_FLAGS or // CMAKE_C_FLAGS used) Debug Release RelWithDebInfo MinSizeRel. CMAKE_BUILD_TYPE:STRING= //Enable/Disable color output during build. CMAKE_COLOR_MAKEFILE:BOOL=ON //CXX compiler. CMAKE_CXX_COMPILER:FILEPATH=C:/MinGW/bin/g++.exe //Flags used by the compiler during all build types. CMAKE_CXX_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_CXX_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //Libraries linked by defalut with all C++ applications. CMAKE_CXX_STANDARD_LIBRARIES:STRING=-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 //C compiler. CMAKE_C_COMPILER:FILEPATH=C:/MinGW/bin/gcc.exe //Flags used by the compiler during all build types. CMAKE_C_FLAGS:STRING= //Flags used by the compiler during debug builds. CMAKE_C_FLAGS_DEBUG:STRING=-g //Flags used by the compiler during release minsize builds. CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG //Flags used by the compiler during release builds (/MD /Ob1 /Oi // /Ot /Oy /Gs will produce slightly less optimized but smaller // files). CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG //Flags used by the compiler during Release with Debug Info builds. CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g //Libraries linked by defalut with all C applications. CMAKE_C_STANDARD_LIBRARIES:STRING=-lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 //Flags used by the linker.
Re: [CMake] Updated: CMake 2.8.7-1
On 3/6/2012 12:53 PM, Robert Dailey wrote: Could you list the mirror URLs for me that were updated? I'm trying a few that are listed in the setup.exe for cygwin but I'm not seeing the new version. Still shows 2.8.4 for the mirrors I tried. Give it some time. I have no control over the mirrors getting updated. They just do over time. By this time next week, I would think all of them should be OK. -Bill -- 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] Impossible to link SDLmain and LibXml2
2012/3/6 julien@redaction-developpez.com:
Hi,
I have a problem with cmake not to compile but to link my .exe.
I use SDL, OpenGL, FMOD, LibXml2 and a personal library. But when I try to
compile my program LibXml2 and SDLmain are not include into the command line
to link my .exe.
Enclosed my CMakeList.txt and CMakeCache.txt and here the line for the
linker into build.make:
Output/shootspace.exe: C:/MinGW/lib/libSDL.dll.a
Output/shootspace.exe: C:/MinGW/lib/libfmodex.a
Output/shootspace.exe: CMakeFiles/shootspace.dir/build.make
Output/shootspace.exe: CMakeFiles/shootspace.dir/objects1.rsp
@$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR)
--red --bold Linking CXX executable Output/shootspace.exe
/c/Program Files (x86)/CMake 2.8/bin/cmake.exe -E remove
-f CMakeFiles/shootspace.dir/objects.a
/C/MinGW/bin/ar.exe cr CMakeFiles/shootspace.dir/objects.a
@CMakeFiles/shootspace.dir/objects1.rsp
/C/MinGW/bin/g++.exe -Wl,--whole-archive
CMakeFiles/shootspace.dir/objects.a -Wl,--no-whole-archive -o
Output/shootspace.exe -Wl,--out-implib,Output/libshootspace.dll.a
-Wl,--major-image-version,0,--minor-image-version,0
-Lsource/lib/gtl/lib/mingw -lmingw32 /C/MinGW/lib/libSDL.dll.a -lpthread
-lglu32 -lopengl32 /C/MinGW/lib/libfmodex.a -lgtl -lkernel32 -luser32
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32
As you can see, LibXml2 library and SDLmain library are found in
CMakeCache.txt but not include in build.make because –lxml2 and –lSDLmain
are missing.
Why ? I do something wrong in my CMakeList.txt ?
yes.
since you did
Find_Package(LibXml2 REQUIRED)
you'll have to:
target_link_libraries(
shootspace
${LIBXML2_LIBRARIES}
and not XML2_LIBRARY
in you CMakeCache.txt you'll see that SDLmain is not found.
//Path to a library.
SDLMAIN_LIBRARY:FILEPATH=SDLMAIN_LIBRARY-NOTFOUND
for SDL I suggest you read the documentation of the module:
cmake --help-module FindSDL
there are some explanation about SDLmain or not.
--
Erk
Le gouvernement représentatif n'est pas la démocratie --
http://www.le-message.org
--
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] Impossible to link SDLmain and LibXml2
Hello Julien, Am Dienstag, 6. März 2012 um 20:58:43 schrieb julien.plu@redaction- developpez.com: Why ? I do something wrong in my CMakeList.txt ? You should use LIBXML2_LIBRARIES [1]. Kind regards Benjamin [1]http://cmake.org/cmake/help/cmake-2-8-docs.html#module:FindLibXml2 -- 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] Impossible to link SDLmain and LibXml2
Thanks, for libXml2 it was indeed LIBXML2_LIBRARIES instead of
LIBXML2_LIBRARY. And for SDLmain it was an error in one on my change on
findSDL.cmake file because I have replaced $ENV{SDLDIR} by another
environment variable.
Thanks again at all of you :-)
Cheers.
---
Julien Plu
Etudiant en 2ème année de Master Ingénierie en Intelligence Artificielle à
lUniversité Montpellier 2.
Mes projets Web sémantique : http://data.lirmm.fr
Page personnelle : http://jplu.developpez.com
Responsable de la rubrique Web sémantique de Developpez.com.
Fichier FOAF (version RDF) : http://jplu.developpez.com/julien
Fichier FOAF (version RDFa) : http://jplu.developpez.com/julien.html
Adresse mail personnelle : julien@redaction-developpez.com
Adresse mail universitaire : julien@etud.univ-montp2.fr
-Message d'origine-
De : cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] De la part de
Benjamin Eikel
Envoyé : mardi 6 mars 2012 21:21
À : cmake@cmake.org
Objet : Re: [CMake] Impossible to link SDLmain and LibXml2
Hello Julien,
Am Dienstag, 6. März 2012 um 20:58:43 schrieb julien.plu@redaction-
developpez.com:
Why ? I do something wrong in my CMakeList.txt ?
You should use LIBXML2_LIBRARIES [1].
Kind regards
Benjamin
[1]http://cmake.org/cmake/help/cmake-2-8-docs.html#module:FindLibXml2
--
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
--
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] math(EXPR) and unary operators
math(EXPR) rejects expressions with negative numbers. This is awful
because math() can reject its own negative results. For example, this
code fails:
math(EXPR negative 1 - 2)
math(EXPR sum 100 + ${negative})
The second expression, 100 + -1, causes an error.
This contradicts cmake --help-command math, which claims, Supported
operators are + - * / % | ^ ~ * / %. They have the same meaning
as they do in c code.
I can write -2 or ~2 in C, but not in CMake. The ~ (bitwise not) seems
impossible to use. My every attempt to use ~ in math() causes an error.
To fix this bug, I taught the grammar about unary operators:
diff --git a/Source/cmExprParser.y b/Source/cmExprParser.y
index 317b0ba..57820ec 100644
--- a/Source/cmExprParser.y
+++ b/Source/cmExprParser.y
@@ -150,6 +150,16 @@ term exp_MOD factor
{$Number$ = $Number1 % $Number3;}
factor:
+value
+{$Number$ = $Number1;}
+|
+exp_MINUS factor
+{$Number$ = -$Number2;}
+|
+exp_NOT factor
+{$Number$ = ~$Number2;}
+
+value:
exp_NUMBER
{$Number$ = $Number1;}
|
I pasted this same patch at http://pastebin.com/7j5Pu3AL
After applying this patch, one must run the bison command from the
comment in cmExprParser.y.
--George Koehler
--
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] Running executables - local targets vs. system binaries
In a number of places in our build, we use compiled binaries via add_custom_command and friends to perform work during the compilation. For the most part we are able to successfully specify the target name used with add_executable in place of a full path to successfully tell CMake to run the locally built binary, but there's a corner case that's causing a bit of trouble. We have locally built versions of several tools that might be found on some systems, but cannot be relied upon to be there in all cases (Windows, in particular, expands the set of can't always depend on it being available significantly.) In some build configurations we want to use our local verisons of these tools even when system versions are present (testing, making sure the version we use supports what we need, etc.). This is where we get into trouble - if the system version of our locally built tool is in the path, and the executable name matches the CMake target name, it looks as though the generated build files will use the system version in preference to the locally built version. Is this expected behavior, and if so is there a setting that can be set to make CMake prefer the local target over the system version in cases where both are present? It doesn't matter much when using systems like Make since I can supply the full path to the locally built target, but for multi-configuration systems like Visual Studio this path changes at build time, not CMake configure time. Any insight appreciated! CY -- 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] Running executables - local targets vs. system binaries
If you want add_custom_command to run a certain executable, simply
give it the full path to that executable: use /full/path/to/tool
instead of tool
If tool is a built thing, you can use
${XYZ_BINARY_DIR}/${CMAKE_CFG_INTDIR}/tool which will properly
expand out to the correct Release or Debug subdirectory when run
with Visual Studio or Xcode.
HTH,
David
On Tue, Mar 6, 2012 at 5:51 PM, Clifford Yapp cliffy...@gmail.com wrote:
In a number of places in our build, we use compiled binaries via
add_custom_command and friends to perform work during the compilation. For
the most part we are able to successfully specify the target name used with
add_executable in place of a full path to successfully tell CMake to run the
locally built binary, but there's a corner case that's causing a bit of
trouble.
We have locally built versions of several tools that might be found on some
systems, but cannot be relied upon to be there in all cases (Windows, in
particular, expands the set of can't always depend on it being available
significantly.) In some build configurations we want to use our local
verisons of these tools even when system versions are present (testing,
making sure the version we use supports what we need, etc.). This is where
we get into trouble - if the system version of our locally built tool is in
the path, and the executable name matches the CMake target name, it looks as
though the generated build files will use the system version in preference
to the locally built version.
Is this expected behavior, and if so is there a setting that can be set to
make CMake prefer the local target over the system version in cases where
both are present? It doesn't matter much when using systems like Make since
I can supply the full path to the locally built target, but for
multi-configuration systems like Visual Studio this path changes at build
time, not CMake configure time.
Any insight appreciated!
CY
--
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
--
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] Running executables - local targets vs. system binaries
On 06.03.12 17:56:41, David Cole wrote:
If you want add_custom_command to run a certain executable, simply
give it the full path to that executable: use /full/path/to/tool
instead of tool
If tool is a built thing, you can use
${XYZ_BINARY_DIR}/${CMAKE_CFG_INTDIR}/tool which will properly
expand out to the correct Release or Debug subdirectory when run
with Visual Studio or Xcode.
Thats not what the cmake manual states:
If COMMAND specifies an executable target (created by ADD_EXECUTABLE) it
will automat‐ ically be replaced by the location of the executable
created at build time.
So either the manual is wrong and one needs to manually construct the
correct paths even for in-project targets or cmake should prefer an
existing target over an executable reachable via PATH.
Andreas
--
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] Running executables - local targets vs. system binaries
On Tue, Mar 6, 2012 at 6:27 PM, Andreas Pakulat ap...@gmx.de wrote:
On 06.03.12 17:56:41, David Cole wrote:
If you want add_custom_command to run a certain executable, simply
give it the full path to that executable: use /full/path/to/tool
instead of tool
If tool is a built thing, you can use
${XYZ_BINARY_DIR}/${CMAKE_CFG_INTDIR}/tool which will properly
expand out to the correct Release or Debug subdirectory when run
with Visual Studio or Xcode.
Thats not what the cmake manual states:
If COMMAND specifies an executable target (created by ADD_EXECUTABLE) it
will automat‐ ically be replaced by the location of the executable
created at build time.
So either the manual is wrong and one needs to manually construct the
correct paths even for in-project targets or cmake should prefer an
existing target over an executable reachable via PATH.
Andreas
--
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
The manual is correct. But so was my earlier reply.
I am not aware of a general problem where CMake gets confused by a
target named something the same as an executable in your PATH... That
should be ok, and CMake should prefer its own target, and generate
build instructions using the full path name of the built target.
My technique simply specifies, explicitly in the CMake code, which
full path name to use for the custom command. I always find that the
most useful technique for resolving possible name conflicts.
Either should work, assuming tool is the name of a CMake target that
you have built.
If there is still a problem, please specify a minimal example that we
can run to reproduce it, and I'm sure somebody here will help figure
out what's going on.
Thx,
David
--
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 configuration times with Microsoft Visual C++
We use the same configuration tests on all platforms in an effort to avoid having large chunks of platform-specific code in our build files, but we pay a price for this on Windows - the same test process is more than an order of magnitude slower with MSVC than (say) Linux. Does CMake launch the MSVC C++ compiler each time it needs to do a TRY_COMPILE or similar test? If so, does anybody know of any techniques for combining tests or some way to run a cl.exe instance as a daemon to which multiple files can be fed without needing a full restart of cl.exe? Cheers, CY -- 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 configuration times with Microsoft Visual C++
On 3/6/2012 9:09 PM, Clifford Yapp wrote: We use the same configuration tests on all platforms in an effort to avoid having large chunks of platform-specific code in our build files, but we pay a price for this on Windows - the same test process is more than an order of magnitude slower with MSVC than (say) Linux. Does CMake launch the MSVC C++ compiler each time it needs to do a TRY_COMPILE or similar test? If so, does anybody know of any techniques for combining tests or some way to run a cl.exe instance as a daemon to which multiple files can be fed without needing a full restart of cl.exe? No, good way to do this on windows. The best you can do is to make sure it tries the windows stuff first, and that you remove as many try-compiles as possible when on Windows. Not only does CMake launch cl.exe, but it will also launch devenv.com with command line build arguments :) It is the only way to make sure that the compile environments are exact. So, you can optimize a build for windows with a bit of work, but there is nothing easy to do from CMake to make this faster. -Bill -- 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] how to configure cmake to help translate?
I've read this link
http://www.cmake.org/Wiki/CMake:How_To_Build_Qt4_Software and I type code
below
set(${PROJECT_NAME}_HDRS
mainwindow.h
item.h
)
set(${PROJECT_NAME}_SRCS
main.cpp
mainwindow.cpp
item.cpp
)
SET(UPDATE_TRANSLATIONS TRUE)
SET(GLOB TRANSLATION_FILES FILES translations/*.ts)
SET(FILES_TO_TRANSLATE )
set(FILES_TO_TRANSLATE ${FILES_TO_TRANSLATE} ${${PROJECT_NAME}_SRCS})
if(UPDATE_TRANSLATIONS)
QT4_CREATE_TRANSLATION(QM_FILE ${CMAKE_SOURCE_DIR}/translations
${FILES_TO_TRANSLATE} ${TRANSLATION_FILES})
else(UPDATE_TRANSLATIONS)
QT4_ADD_TRANSLATION(${CMAKE_SOURCE_DIR}/translations
${TRANSLATION_FILES})
endif(UPDATE_TRANSLATIONS)
where translations is folder in source folder, but cmake don't return any
result. Help me fix this bug! Thank in advance!
--
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] Ninja + CMake on a dashboard?
On Tue, Mar 6, 2012 at 8:58 PM, Clifford Yapp cliffy...@gmail.com wrote: We *could*, if popular demand is high enough, merge it in anyway and call it experimental to start with, or we could get it right all the way before we merge to 'master' and put it out in an official CMake release. What would be involved with fixing the remaining OSX issues? Do we need CMake changes, ninja changes, both...? Obviously full support would be preferable, unless it won't be happening for quite some time - I would agree that if non-GUI apps won't work on OSX it would be better to limit an activation of Ninja to those platforms where it will Work As Expected. So contrary to what I have said at the beginning of this thread. It seems that merging it master will generate more bug report than patches to fix the issue. If it is the case, I prefer to disable it. I will try to fix them ASAP anyway. Cheers, -- Nicolas Desprès -- 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-commits] CMake branch, next, updated. v2.8.7-3067-gbc66108
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via bc661082500d1b66e06b621ce2c565f3fa1e8361 (commit)
via c91a54db3766aea8f8ab9d5a011db3bba67b12d4 (commit)
from 666c6d9a63f98daed3a1a3000b0249df1be04731 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc661082500d1b66e06b621ce2c565f3fa1e8361
commit bc661082500d1b66e06b621ce2c565f3fa1e8361
Merge: 666c6d9 c91a54d
Author: Alexander Neundorf neund...@kde.org
AuthorDate: Tue Mar 6 15:18:50 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Mar 6 15:18:50 2012 -0500
Merge topic 'find_package_fatal_error_if_required_and_config_not_found'
into next
c91a54d find_package: error out if REQUIRED Config has not been found
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c91a54db3766aea8f8ab9d5a011db3bba67b12d4
commit c91a54db3766aea8f8ab9d5a011db3bba67b12d4
Author: Alex Neundorf neund...@kde.org
AuthorDate: Tue Mar 6 21:16:24 2012 +0100
Commit: Alex Neundorf neund...@kde.org
CommitDate: Tue Mar 6 21:16:24 2012 +0100
find_package: error out if REQUIRED Config has not been found
If in Config mode a configuration file could not be found, cmake printed
an error, but did not actually stop processing. With SetFatalErrorOccured
it does.
Alex
diff --git a/Source/cmFindPackageCommand.cxx b/Source/cmFindPackageCommand.cxx
index 9177162..f8139f9 100644
--- a/Source/cmFindPackageCommand.cxx
+++ b/Source/cmFindPackageCommand.cxx
@@ -1062,6 +1062,10 @@ bool cmFindPackageCommand::HandlePackageMode()
this-Makefile-IssueMessage(
this-Required? cmake::FATAL_ERROR : cmake::WARNING, e.str());
+if (this-Required)
+ {
+ cmSystemTools::SetFatalErrorOccured();
+ }
if (!aw.str().empty())
{
---
Summary of changes:
Source/cmFindPackageCommand.cxx |4
1 files changed, 4 insertions(+), 0 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-563-g480ba64
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 480ba6434399052553b31c97e399b44a1491aac9 (commit) via 89403bf87f21d9bccb9c73afb5df914cb88ec9ee (commit) from ec50093be768c9fa9384cc42a4d1f331f0264b39 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=480ba6434399052553b31c97e399b44a1491aac9 commit 480ba6434399052553b31c97e399b44a1491aac9 Merge: ec50093 89403bf Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:24:40 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:24:40 2012 -0500 Merge topic 'rename-used-commands' 89403bf Rename UsedCommands to FinalPassCommands --- Summary of changes: Source/cmMakefile.cxx | 10 +- Source/cmMakefile.h |8 +--- 2 files changed, 6 insertions(+), 12 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-577-g155e644
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 155e6443657800eeb9e4dd20aa00a21b4610148e (commit) via 2d59c9ab17c4af84ddb09ef7da89a37871d381a7 (commit) from 9c77a1492aedc61fc990b3fc7ad06dbc5cc0bec4 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=155e6443657800eeb9e4dd20aa00a21b4610148e commit 155e6443657800eeb9e4dd20aa00a21b4610148e Merge: 9c77a14 2d59c9a Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:25:38 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:25:38 2012 -0500 Merge topic 'fix-mingw-introspection' 2d59c9a cmcurl: Do not hard-coded Windows check results for MinGW (#13001) --- Summary of changes: Utilities/cmcurl/CMakeLists.txt |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-579-gef66137
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via ef6613718ee899d14f9021387742084b1ee33098 (commit) via 9012be20c526445e0d2e2ca6878308bb88dba9cf (commit) from 155e6443657800eeb9e4dd20aa00a21b4610148e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ef6613718ee899d14f9021387742084b1ee33098 commit ef6613718ee899d14f9021387742084b1ee33098 Merge: 155e644 9012be2 Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:26:04 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:26:04 2012 -0500 Merge topic 'remove-CheckSourceTree-cvs-support' 9012be2 CheckSourceTree: Remove CVS checkout support (#13001) --- Summary of changes: Tests/CMakeTests/CMakeLists.txt |5 +- Tests/CMakeTests/CheckSourceTreeTest.cmake.in | 87 ++--- 2 files changed, 7 insertions(+), 85 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-586-gf2e98ed
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via f2e98ed420d9b99ed0bae8d683a99dcc89451e4f (commit) via e3336025672383c6345989af9539943a74850614 (commit) from 5aa0f24350fbb59daa3e7269ada2cf1caf9abd1c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f2e98ed420d9b99ed0bae8d683a99dcc89451e4f commit f2e98ed420d9b99ed0bae8d683a99dcc89451e4f Merge: 5aa0f24 e333602 Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:26:41 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:26:41 2012 -0500 Merge topic 'fix-msys-cvs-local-repo' e333602 Fix MSYS CVS local test repo path format (#13001) --- Summary of changes: Tests/CTestUpdateCVS.cmake.in| 13 + Tests/ExternalProject/CMakeLists.txt | 12 2 files changed, 25 insertions(+), 0 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-591-g7fbd323
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 7fbd323f8056ce6deda71a88d07f8f2a3ca98e76 (commit) via aef248a4ff675aeb4af6aa44322bed76f4bcf990 (commit) via e26657103fa95b2a898e438ec6eb982a3c0bf3cc (commit) from 481b2aa1010f160c17acce72217e91be128ab033 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7fbd323f8056ce6deda71a88d07f8f2a3ca98e76 commit 7fbd323f8056ce6deda71a88d07f8f2a3ca98e76 Merge: 481b2aa aef248a Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:27:08 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:27:08 2012 -0500 Merge topic 'remove-unused-members' aef248a Remove cmExprParserHelper::SetLineFile() e266571 Remove UnionsAvailable member from 2 classes --- Summary of changes: Source/cmCommandArgumentParserHelper.h |1 - Source/cmExprParserHelper.cxx |6 -- Source/cmExprParserHelper.h|3 --- 3 files changed, 0 insertions(+), 10 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-593-g663832e
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 663832eb44b11e0e39f387aedf35ceeafe6360d8 (commit) via b43cd1252c9e7d5dfe7ed9ef9bbd4671b38a535d (commit) from 7fbd323f8056ce6deda71a88d07f8f2a3ca98e76 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=663832eb44b11e0e39f387aedf35ceeafe6360d8 commit 663832eb44b11e0e39f387aedf35ceeafe6360d8 Merge: 7fbd323 b43cd12 Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:27:28 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:27:28 2012 -0500 Merge topic 'test-getpropery' b43cd12 add test for get_property() errors --- Summary of changes: Tests/CMakeTests/CMakeLists.txt|1 + Tests/CMakeTests/GetProperty-Bad-Argument.cmake|1 + Tests/CMakeTests/GetProperty-Bad-Directory.cmake |1 + Tests/CMakeTests/GetProperty-Bad-Scope.cmake |1 + Tests/CMakeTests/GetProperty-Bad-Target.cmake |1 + Tests/CMakeTests/GetProperty-Bad-Test.cmake|1 + Tests/CMakeTests/GetProperty-Doc-Properties.cmake | 10 ++ Tests/CMakeTests/GetProperty-Global-Name.cmake |1 + .../CMakeTests/GetProperty-Missing-Argument.cmake |1 + Tests/CMakeTests/GetProperty-No-Cache.cmake|1 + Tests/CMakeTests/GetProperty-No-Property.cmake |1 + Tests/CMakeTests/GetProperty-No-Source.cmake |1 + Tests/CMakeTests/GetProperty-No-Target.cmake |1 + Tests/CMakeTests/GetProperty-No-Test.cmake |1 + Tests/CMakeTests/GetProperty-Variable-Name.cmake |1 + Tests/CMakeTests/GetPropertyTest.cmake.in | 98 16 files changed, 122 insertions(+), 0 deletions(-) create mode 100644 Tests/CMakeTests/GetProperty-Bad-Argument.cmake create mode 100644 Tests/CMakeTests/GetProperty-Bad-Directory.cmake create mode 100644 Tests/CMakeTests/GetProperty-Bad-Scope.cmake create mode 100644 Tests/CMakeTests/GetProperty-Bad-Target.cmake create mode 100644 Tests/CMakeTests/GetProperty-Bad-Test.cmake create mode 100644 Tests/CMakeTests/GetProperty-Doc-Properties.cmake create mode 100644 Tests/CMakeTests/GetProperty-Global-Name.cmake create mode 100644 Tests/CMakeTests/GetProperty-Missing-Argument.cmake create mode 100644 Tests/CMakeTests/GetProperty-No-Cache.cmake create mode 100644 Tests/CMakeTests/GetProperty-No-Property.cmake create mode 100644 Tests/CMakeTests/GetProperty-No-Source.cmake create mode 100644 Tests/CMakeTests/GetProperty-No-Target.cmake create mode 100644 Tests/CMakeTests/GetProperty-No-Test.cmake create mode 100644 Tests/CMakeTests/GetProperty-Variable-Name.cmake create mode 100644 Tests/CMakeTests/GetPropertyTest.cmake.in hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-595-ge872b0d
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via e872b0d2b8af28297ce4d3dfb9f751003e50e65c (commit) via 761c146a4c02c76adafb233606dfe50157857c87 (commit) from 663832eb44b11e0e39f387aedf35ceeafe6360d8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e872b0d2b8af28297ce4d3dfb9f751003e50e65c commit e872b0d2b8af28297ce4d3dfb9f751003e50e65c Merge: 663832e 761c146 Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:27:44 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:27:44 2012 -0500 Merge topic 'win32_executable-and-macosx_bundle-initializers' 761c146 Add default initializers for WIN32_EXECUTABLE and MACOSX_BUNDLE --- Summary of changes: Source/cmDocumentVariables.cxx | 16 Source/cmTarget.cxx| 10 -- 2 files changed, 24 insertions(+), 2 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v2.8.7-597-g50f9db9
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, master has been updated via 50f9db9b00dedd53789ae446475fef790e2534df (commit) via 635bf50c27aef184bfa1698953dd44361e1fb2f9 (commit) from e872b0d2b8af28297ce4d3dfb9f751003e50e65c (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=50f9db9b00dedd53789ae446475fef790e2534df commit 50f9db9b00dedd53789ae446475fef790e2534df Merge: e872b0d 635bf50 Author: David Cole david.c...@kitware.com AuthorDate: Tue Mar 6 15:27:54 2012 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Tue Mar 6 15:27:54 2012 -0500 Merge topic 'skip-install-rpath' 635bf50 Add an option to skip RPATH during installation. --- Summary of changes: Modules/CMakeGenericSystem.cmake|3 +++ Source/cmComputeLinkInformation.cxx |1 + Source/cmDocumentVariables.cxx | 18 +- Source/cmTarget.cxx |6 -- 4 files changed, 25 insertions(+), 3 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.7-3089-g1cee05a
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 1cee05a76dbf24262cf3bd883d68eb9bb28e25a5 (commit)
via b28e7fa174798717ebf8e18b8d97755d3568b04d (commit)
from 638bcf23310fef7a74c3f52292d151e6b8184c76 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1cee05a76dbf24262cf3bd883d68eb9bb28e25a5
commit 1cee05a76dbf24262cf3bd883d68eb9bb28e25a5
Merge: 638bcf2 b28e7fa
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Mar 6 18:49:56 2012 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Tue Mar 6 18:49:56 2012 -0500
Merge topic 'fix-12189-support-SBCS-in-VS' into next
b28e7fa VS6: Avoid SBCS test on VS6 (#12189)
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b28e7fa174798717ebf8e18b8d97755d3568b04d
commit b28e7fa174798717ebf8e18b8d97755d3568b04d
Author: David Cole david.c...@kitware.com
AuthorDate: Tue Mar 6 18:41:56 2012 -0500
Commit: David Cole david.c...@kitware.com
CommitDate: Tue Mar 6 18:45:51 2012 -0500
VS6: Avoid SBCS test on VS6 (#12189)
The previous commit, df19b9ca, assumed that the corresponding
_UNICODE functionality in the VS6 generator actually worked.
That turns out not to be the case. Unicode definition does not
actually suppress _MBCS definition, so neither does this new
code...
Don't test it here, since the patch submitter for _SBCS does
not need VS6 support.
If somebody needs _UNICODE and _SBCS support to suppress the
definition of _MBCS in the VS6 generator, it is work yet to do.
Patches welcome.
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index da656d4..3e1a962 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -1306,7 +1306,9 @@ ${CMake_BINARY_DIR}/bin/cmake -DVERSION=master -P
${CMake_SOURCE_DIR}/Utilities/
endif()
IF(${CMAKE_TEST_GENERATOR} MATCHES Visual Studio)
-ADD_TEST_MACRO(SBCS SBCS)
+IF(NOT MSVC60)
+ ADD_TEST_MACRO(SBCS SBCS)
+ENDIF(NOT MSVC60)
ADD_TEST(VSExternalInclude ${CMAKE_CTEST_COMMAND}
--build-and-test
---
Summary of changes:
Tests/CMakeLists.txt |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
