Re: [cmake-developers] [PATCH] New module: FindIce.cmake
On Thu, Aug 21, 2014 at 02:47:24PM +0200, Rolf Eike Beer wrote: Roger Leigh wrote: On Sun, Aug 17, 2014 at 05:22:38PM +0100, Roger Leigh wrote: On Sun, Aug 17, 2014 at 05:50:58PM +0200, Rolf Eike Beer wrote: Am Sonntag, 17. August 2014, 16:21:24 schrieb Roger Leigh: On Fri, Aug 15, 2014 at 12:31:17AM +0100, Roger Leigh wrote: OK. I'll have to read up on this and see what needs doing. In the meantime, I've attached a revised patch with all the above corrections included. Based on the comments made on my other FindXerces patch, I've updated this patch to also use current naming and usage conventions. I hope this is all OK with you. +if((MSVC_VERSION EQUAL 1400) OR (MSVC_VERSION GREATER 1400 AND MSVC_VERSION LESS 1500)) if((NOT MSVC_VERSION VERSION_LESS 1400 AND MSVC_VERSION LESS 1500) Thanks, I've fixed this now in the attached patch. One single line change to the patch attached, to add support for FreeBSD, which uses a different slice directory (unversioned share/Ice). Pushed, including some cleanups: -remove text in else(), endif() and so on (applies also to FindXerces) -if (...) else() can be if (NOT ...) -used elseif for MSVC version scanning, once you have found one version the other if's can't be true Please check if I have messed something up. I've looked through the changes for both files and I can't see any problems there. I tested FindXerces on Linux and MacOS and can't see any changes in behaviour. Likewise I tested FindIce on Linux, MacOS and Windows in a variety of different combinations of compiler and Ice versions and also didn't see any problems. I've pushed the cleanups into our local git repositories and they will be picked up by our automated jenkins CI testing; I'll have the results of that by Monday, but I wouldn't expect it to be any different from the manual testing I've already done. Many thanks, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0015101]: Imported libraries go out of scope after call to target_link_libraries().
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=15101 == Reported By:Björn Piltz Assigned To: == Project:CMake Issue ID: 15101 Category: CMake Reproducibility:always Severity: minor Priority: normal Status: new == Date Submitted: 2014-08-22 08:29 EDT Last Modified: 2014-08-22 08:29 EDT == Summary:Imported libraries go out of scope after call to target_link_libraries(). Description: I have a project where module lib - a library - depends on Qt, so it calls find_package(Qt5 ...) and target_link_libraries(lib Qt5::Core). Later I call target_link_libraries(app lib). The cmake configure step runs through without problems, but the generate step halts with the message: Target app links to target Qt5::Core but the target was not found. Perhaps a find_package() call is missing for an IMPORTED target, or an ALIAS target is missing? According to the documentation the target Qt5::Core is out of scope for 'app' since app is not in a subdirectory of the directory where add_library(... IMPORTED) was made, but I would argue that this is a bug since the target was in scope when the call add_library(lib Qt5::Core) was made. This issue is not specific to Qt and I'm aware that it could be fixed on their side by calling add_library(... IMPORTED GLOBAL). I'm hoping it could be fixed on the cmake side, though. Steps to Reproduce: git clone https://github.com/bjornpiltz/cmake_bug.git cmake_bug mkdir work cd work cmake -DCMAKE_PREFIX_PATH=Qt5/lib/cmake/ ../cmake_bug/ Additional Information: This issue is platform independent. == Issue History Date ModifiedUsername FieldChange == 2014-08-22 08:29 Björn PiltzNew Issue == -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On Fri, Aug 22, 2014 at 8:44 AM, Brad King brad.k...@kitware.com wrote:
On 08/21/2014 03:25 PM, Richard Shaw wrote:
So the string command should be something like:
string(REPLACE ; wxWidgets_CXX_FLAGS_str ${wxWidgets_CXX_FLAGS})
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS_str})
Yes, and followed by unset(wxWidgets_CXX_FLAGS_str) to clear the
variable to not present it to applications.
Ok, hopefully this is better. I'm reading up on git but I still fubmble
around a bit...
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=8e702cabfb149d1c67af725a3952af7034a2981d
Thanks,
Richard
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On 08/22/2014 10:02 AM, Richard Shaw wrote: Ok, hopefully this is better. I'm reading up on git but I still fubmble around a bit... http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=8e702cabfb149d1c67af725a3952af7034a2981d Good. Please rebase/rewrite the topic and force-push it back to the stage to get rid of the extra merges and make it one commit again. Also please follow up with a change to drop the MSG debugging macro that was left in there before. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On Thu, Aug 21, 2014 at 2:21 PM, Brad King brad.k...@kitware.com wrote:
On 08/21/2014 02:30 PM, Richard Shaw wrote:
if (wxWidgets_CXX_FLAGS)
+# Flags are expected to be a string here, not a list.
+string(REPLACE ; wxWidgets_CXX_FLAGS ${wxWidgets_CXX_FLAGS})
set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS})
Thanks. However, we shouldn't leak our local modification to the value
of wxWidgets_CXX_FLAGS, so the substitution should be done with the
result stored in a temporary local variable.
Also, please start the commit message in UsewxWidgets:
Ok, all updates have been incorporated, so I'm looking for an ACK to know
if it appears ready to push into next.
http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4
Thanks,
Richard
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
Simple logic update to check if we're cross-compiling to determine if unix or win32 path find style should be used. FindwxWidgets: Improve path detection logic when cross-compiling. Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review Request] Topic wxWidgets-cflags
On 08/22/2014 12:27 PM, Richard Shaw wrote: Ok, all updates have been incorporated, so I'm looking for an ACK Looks good, thanks. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
On 08/22/2014 12:39 PM, Richard Shaw wrote: Simple logic update to check if we're cross-compiling to determine if unix or win32 path find style should be used. FindwxWidgets: Improve path detection logic when cross-compiling. [snip] +else(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) + set(wxWidgets_FIND_STYLE unix) +endif(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) Please use empty else() and endif(). Otherwise, looks good. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
On Fri, Aug 22, 2014 at 12:08 PM, Brad King brad.k...@kitware.com wrote: On 08/22/2014 12:39 PM, Richard Shaw wrote: Simple logic update to check if we're cross-compiling to determine if unix or win32 path find style should be used. FindwxWidgets: Improve path detection logic when cross-compiling. [snip] +else(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) + set(wxWidgets_FIND_STYLE unix) +endif(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) Please use empty else() and endif(). Otherwise, looks good. Fixed: http://cmake.org/gitweb?p=stage/cmake.git;a=commitdiff;h=33286235048495ceafb636d549d9a4e8891967ae Thanks, Richard -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [Review request] FindwxWidgets: Improve path detection logic when cross-compiling.
On 08/22/2014 01:23 PM, Richard Shaw wrote: Please use empty else() and endif(). Otherwise, looks good. Fixed: [snip] #= +# Determine whether unix or win32 paths should be used #= -if(WIN32 AND NOT CYGWIN AND NOT MSYS) +if(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING) set(wxWidgets_FIND_STYLE win32) else() - if(UNIX OR MSYS) -set(wxWidgets_FIND_STYLE unix) - endif() + set(wxWidgets_FIND_STYLE unix) endif() Good, thanks. Please merge for testing. -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [CMake] Linker error with sub project's static libs
Hello Leif, Are your libraries mutually dependent? You may be hitting the mutually-dependent static library problem. Look for the word mutual near the end of http://www.cmake.org/cmake/help/v3.0/command/target_link_libraries.html, that section explains some of what is going on. yes it is mutually, ui_lib creates a SchematicView, which is derived from GraphicView. SchematicView's instance is in ui_schematic_lib, where GraphicsView is in ui_lib. Probably I should stay the files inside these directory and add them to the source in ui_lib project as the docs suggested. Thanks, Olaf Unless your code snippets are incomplete, I'm missing the following statement in ./source/eea/ui/CMakeLists.txt target_link_libraries(eea_ui_lib eea_ui_schematic_lib) I'm not sure this is causing the link error, but it's worth a try. thank you a lot, this solves the linker problem - I have to add these twice, reference to the other lib each time. Furthermore, I think the order of add_subdirectory(), add_library(), and target_link_libraries() is important. You might want to check those as well. The order matches of course, but I haven't never such linker problems. The first time I'm using target_link_lib for a library self. The reason is not clear for me. What happens under the hood here? Thanks, Olaf -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/ opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Linker error with sub project's static libs
Hi Olaf, See my reply below inline. On 21/08/14 20:19, Olaf Peter wrote: Hello Marcel, Olaf, Unless your code snippets are incomplete, I'm missing the following statement in ./source/eea/ui/CMakeLists.txt target_link_libraries(eea_ui_lib eea_ui_schematic_lib) I'm not sure this is causing the link error, but it's worth a try. thank you a lot, this solves the linker problem - I have to add these twice, reference to the other lib each time. Furthermore, I think the order of add_subdirectory(), add_library(), and target_link_libraries() is important. You might want to check those as well. The order matches of course, but I haven't never such linker problems. The first time I'm using target_link_lib for a library self. The reason is not clear for me. What happens under the hood here? Libraries can depend on one another. If code that produces libB uses functions that are implemented in code that produces libA, then libB depends on libA. When creating static libraries this doesn't make much of a difference; after all a static library is just a bunch of object files. However, when creating shared libraries it does. Shared library libB will record internally that it depends on libA; something a static library cannot do. Suppose you're linking a main program that only uses functions defined in libB. When using shared libraries, you only need to link your main program against libB; remember, libB has recorded internally that it depends on libA. However, when using static libraries you need to link against libB and libA, even though your main program doesn't use any functions in libA. CMake to the rescue! The only thing you have to tell CMake is that libB depends on libA, using target_link_libraries(B A). CMake will then make sure that the correct libraries on put on the link line in the correct order. There's only one exception: circular dependencies. In that case you may need to help CMake a bit. IMHO you should try very hard to avoid circular library dependencies; they are a real PITA. Thanks, Olaf Cheers, Marcel Loose. attachment: loose.vcf-- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command doesn't know about target; but get_target_property does
On 22.08.2014 02:15, Braden McDaniel wrote:
Ah. Bummer.
Well, as you might have guessed, I'm trying to address an issue where
the LOCATION property of a target (EXPORT_TARGET, in the example above)
was being used. Is there some way I can get this information about the
target that doesn't involve modifying the CMakeLists.txt in each
subdirectory where a target of interest resides?
Perhaps something like:
file(GENERATE
OUTPUT ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$CONFIG
CONTENT $TARGET_FILE:${EXPORT_TARGET}
)
Or if you want to keep this at build time a custom command with the
OUTPUT signature and
e.g. a custom target that depends on that output.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Behaviour of FindPythonInterp appears suboptimal
I thought using FindPythonInterp would be more portable than simply invoking python directly (i.e. using $PYTHON_EXECUTABLE). However, this does not appear to be the case. I'd be interested to know if this is intentional or if I'm doing something wrong. I've tried using find_package(PythonInterp 2.6.0 REQUIRED) on a variety of systems. The software in question works with any python 2.6 or 2.7 version. On Debian, with the default python 2.7 installed, it picked up python 2.6.8 (from python2.6-minimal) which lacked all the required modules. /usr/bin/python was 2.7 and matched the version requirement, and had all the required modules available. On Windows, with an active virtualenv, it doesn't use the virtualenv python on the path, but an entirely different version without the modules I need available. Similar problems seen for Ubuntu. I think the general problem here is that it tries to be too clever, and tries to find a lower version in preference to a perfectly suitable newer version, and even the version on the path. This includes using virtualenv, where I've carefully gone to the effort of setting up a custom environment for the purpose only to have it be ignored. I would have expected that if the default path contained python, python2 or python2.7, these should all be preferred (in order) over python2.6 or any autodetected version not on the path, if the version meets the requirement from find_package. The current behaviour gets it wrong in almost every situation except where there's only a single version to choose from! Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Behaviour of FindPythonInterp appears suboptimal
Roger Leigh wrote: I thought using FindPythonInterp would be more portable than simply invoking python directly (i.e. using $PYTHON_EXECUTABLE). However, this does not appear to be the case. I'd be interested to know if this is intentional or if I'm doing something wrong. I've tried using find_package(PythonInterp 2.6.0 REQUIRED) on a variety of systems. The software in question works with any python 2.6 or 2.7 version. On Debian, with the default python 2.7 installed, it picked up python 2.6.8 (from python2.6-minimal) which lacked all the required modules. /usr/bin/python was 2.7 and matched the version requirement, and had all the required modules available. In case you want the newest version of any Python major, as in your case, try find_package(PythonInterp 2 REQUIRED). But you are right, this would also successfully return you a 2.5. Greetings, Eike -- signature.asc Description: This is a digitally signed message part. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Behaviour of FindPythonInterp appears suboptimal
I thought using FindPythonInterp would be more portable than simply invoking python directly (i.e. using $PYTHON_EXECUTABLE). In case you want the newest version of any Python major, as in your case, try find_package(PythonInterp 2 REQUIRED). But you are right, this would also successfully return you a 2.5. Or, if you want to prefer the python in the environment PATH, and then do your own version check to make sure it's suitable, use something like this: # http://www.cmake.org/cmake/help/v3.0/command/find_program.html find_program(PYTHON_EXECUTABLE python PATHS ENV PATH # look in the PATH environment variable NO_DEFAULT_PATH # do not look anywhere else... ) find_package(PythonInterp) And then after the find_package, you can do your own version check with the variables: PYTHON_VERSION_MAJOR='2' PYTHON_VERSION_MINOR='7' PYTHON_VERSION_PATCH='6' PYTHON_VERSION_STRING='2.7.6' and the VERSION_GREATER / VERSION_LESS arguments to the if command. HTH, David C. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command doesn't know about target; but get_target_property does
On Fri, 2014-08-22 at 12:37 +0200, Nils Gladitz wrote:
On 22.08.2014 02:15, Braden McDaniel wrote:
Ah. Bummer.
Well, as you might have guessed, I'm trying to address an issue where
the LOCATION property of a target (EXPORT_TARGET, in the example above)
was being used. Is there some way I can get this information about the
target that doesn't involve modifying the CMakeLists.txt in each
subdirectory where a target of interest resides?
Perhaps something like:
file(GENERATE
OUTPUT ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$CONFIG
CONTENT $TARGET_FILE:${EXPORT_TARGET}
)
Or if you want to keep this at build time a custom command with the
OUTPUT signature and
e.g. a custom target that depends on that output.
Actually, I'd rather not do it at build time; I just didn't realize I
could avoid it. That should work quite nicely. Thanks!
--
Braden McDaniel bra...@endoframe.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] Preferred way to find Qt5 Plugins with CMake 3.x
I am trying to locate specific plugins from the Qt5 installation. I guess in previous iterations of FindQt4 possibly the QT_PLUGINS_DIR may have been defined because I am using this variable in my Qt4 based codes. I am still trying to wade my way through Qt5 so I maybe missing something obvious on how to do this. Any help is much appreciated. Thanks Mike Jackson dream3d.bluequarz.net -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] Preferred way to find Qt5 Plugins with CMake 3.x
To answer my own question, this bit of code gets me started:
foreach(plugin ${Qt5Gui_PLUGINS})
get_target_property(_loc ${plugin} LOCATION)
message(Core Plugin ${plugin} is at location ${_loc})
endforeach()
Now I need to find the debug versions of the library.?
http://qt-project.org/doc/qt-5/cmake-manual.html
…
Looking on Google gives me this bit of Code:
# Find the QtWidgets library
find_package(Qt5 COMPONENTS Core Widgets Network Gui Concurrent)
get_target_property(qjpeg_loc_release Qt5::QJpegPlugin LOCATION_Release)
message(QJpeg DLL: ${qjpeg_loc_release})
get_target_property(qjpeg_loc Qt5::QJpegPlugin LOCATION_Debug)
message(QJpeg DLL: ${qjpeg_loc})
Interestingly on OS X 10.8.5 with CMake 3.0.1 and Qt5 self built I get the
following output:
QJpeg DLL: /Users/Shared/Toolkits/Qt-5.3.1/plugins/imageformats/libqjpeg.dylib
QJpeg DLL: /Users/Shared/Toolkits/Qt-5.3.1/plugins/imageformats/libqjpeg.dylib
but on Windows 7x64 with VS2013 and Qt5 (Downloaded from qt-project.org). I get
the following:
QJpeg DLL:
C:/Developer/x64/Qt5.3.1/5.3/msvc2013_64_opengl/plugins/imageformats/qjpeg.dll
QJpeg DLL:
C:/Developer/x64/Qt5.3.1/5.3/msvc2013_64_opengl/plugins/imageformats/qjpegd.dll
I know when I configured Qt5 on OS X i used -debug-and-release and in fact
there are _debug versions of the plugins on OS X? Anyone have any thoughts on
this? I know in reality on OS X I can mix-n-match Release and Debug libraries
but I just want to make sure I am not missing something critical? I have not
even tried Linux yet
Thanks for any clarifications
Mike Jackson
On Aug 22, 2014, at 10:02 AM, Michael Jackson mike.jack...@bluequartz.net
wrote:
I am trying to locate specific plugins from the Qt5 installation. I guess in
previous iterations of FindQt4 possibly the QT_PLUGINS_DIR may have been
defined because I am using this variable in my Qt4 based codes. I am still
trying to wade my way through Qt5 so I maybe missing something obvious on how
to do this. Any help is much appreciated.
Thanks
Mike Jackson
dream3d.bluequarz.net
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command doesn't know about target; but get_target_property does
Nils Gladitz nilsgladitz@... writes:
Perhaps something like:
file(GENERATE
OUTPUT ${CMAKE_BINARY_DIR}/${LIB_PATHS}/${EXPORT_TARGET}_$CONFIG
CONTENT $TARGET_FILE:${EXPORT_TARGET}
)
Actually, upon closer inspection, it looks like this doesn't work because
$TARGET_FILE:${EXPORT_TARGET} won't be aware of the current configuration at
CMake
configure-time. I'm trying to get the configuration-dependent path of the
emitted library.
(And I need to support Windows project files.)
Or if you want to keep this at build time a custom command with the
OUTPUT signature and
e.g. a custom target that depends on that output.
It's not clear to me that this approach would solve the above problem.
Braden
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command doesn't know about target; but get_target_property does
On 22.08.2014 18:18, Braden McDaniel wrote:
Actually, upon closer inspection, it looks like this doesn't work because
$TARGET_FILE:${EXPORT_TARGET} won't be aware of the current configuration
at CMake
configure-time. I'm trying to get the configuration-dependent path of the
emitted library.
(And I need to support Windows project files.)
It generates one file per configuration (see the $CONFIG generator
expression at the end of the output filename)
and uses the configuration specific expansion of $TARGET_FILE
respectively.
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] add_custom_command and CONFIG-dependent output
I'm trying to do this:
set(LIB_STAGEDIR ${STAGEDIR}/lib/$CONFIG)
add_custom_command(
OUTPUT ${LIB_STAGEDIR}
COMMAND ${CMAKE_COMMAND} -E make_directory ${LIB_STAGEDIR}
)
…and CMake complains thusly:
add_custom_command called with OUTPUT containing a . This
character is
not allowed.
Is there some way to specify OUTPUT when it is dependent on the value
of $CONFIG or similar?
--
Braden McDaniel
bra...@endoframe.com
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] add_custom_command and CONFIG-dependent output
Use ${CMAKE_CFG_INTDIR} in the context of add_custom_command OUTPUT,
not $CONFIG.
You may also use that in the COMMAND arguments.
See documentation here:
http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_CFG_INTDIR.html
The $ generator expressions are relatively new, and do not work in
all contexts that you might expect yet. CMAKE_CFG_INTDIR has been
around for quite some time, though, and works very well with custom
commands.
HTH,
David C.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
[CMake] CMake Error With No Description
Hello all, I have a working (in Linux) CMake project and am now trying to make it cross-platform. I'm nearly there! CMake generates the Makefiles without error but upon trying to run Make, things die. Here's the output from make VERBOSE=1 C:\Users\David\Documents\GitHub\PropWaremake VERBOSE=1 C:/Users/David/cmake-3.0.1-win32-x86/bin/cmake.exe -HC:/Users/David/Documents/GitHub/PropWare -BC:/Users/David/Documents/GitHub/PropWare --check-build-system CMakeFiles/Makefile.cmake 0 C:/Users/David/cmake-3.0.1-win32-x86/bin/cmake.exe -E cmake_progress_start C:/Users/David/Documents/GitHub/PropWare/CMakeFiles C:/Users/David/Documents/GitHub/PropWare/CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory `C:/Users/David/Documents/GitHub/PropWare' make -f simple/cog/CMakeFiles/Simple_cog.dir/build.make simple/cog/CMakeFiles/Simple_cog.dir/depend make[2]: Entering directory `C:/Users/David/Documents/GitHub/PropWare' C:/Users/David/cmake-3.0.1-win32-x86/bin/cmake.exe -E cmake_depends Unix Makefiles C:/Users/David/Documents/GitHub/PropWare C:/Users/David/Documents/GitHub/PropWare/simple/cog C:/Users/David/Documents/GitHub/PropWare C:/Users/David/Documents/GitHub/PropWare/simpl e/cog C:/Users/David/Documents/GitHub/PropWare/simple/cog/CMakeFiles/Simple_cog.dir/DependInfo.cmake --color= make[2]: *** [simple/cog/CMakeFiles/Simple_cog.dir/depend] Error 1 make[2]: Leaving directory `C:/Users/David/Documents/GitHub/PropWare' make[1]: *** [simple/cog/CMakeFiles/Simple_cog.dir/all] Error 2 make[1]: Leaving directory `C:/Users/David/Documents/GitHub/PropWare' make: *** [all] Error 2 C:\Users\David\Documents\GitHub\PropWare A note: yes, it is set to Unix Makefiles. Yes, that is on purpose - a copy of GNU Make is included in the compiler package for this project. Anyone have ideas on what to look for? I'm completely lost. Thanks, David -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
[Cmake-commits] CMake branch, next, updated. v3.0.1-5013-g5c9b7cd
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 5c9b7cdd52158b5255a3ad204a88a11c528db33f (commit)
via e30e4a83729c9b038b252e0a004e9b5af31c8fc3 (commit)
via 97a900623eb87fcc64f6dfc78985bc813f1669ee (commit)
from 73c5a58100f075a22068da3689c0e7313adc1c87 (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=5c9b7cdd52158b5255a3ad204a88a11c528db33f
commit 5c9b7cdd52158b5255a3ad204a88a11c528db33f
Merge: 73c5a58 e30e4a8
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Aug 22 09:35:36 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 22 09:35:36 2014 -0400
Merge topic 'vs-windows-apps' into next
e30e4a83 Help: Add notes for topic 'vs-windows-apps'
97a90062 VS: Do not compile C sources as WinRT (#15100)
diff --cc Source/cmVisualStudio10TargetGenerator.cxx
index c6b78ce,6f1fe52..309ceb6
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@@ -1486,12 -1462,11 +1488,16 @@@ bool cmVisualStudio10TargetGenerator::O
{
clOptions.AddFlag(CompileAs, compileAs);
}
+ if(noWinRT)
+ {
+ clOptions.AddFlag(CompileAsWinRT, false);
+ }
clOptions.Parse(flags.c_str());
+ if(clOptions.HasFlag(AdditionalIncludeDirectories))
+{
+clOptions.AppendFlag(AdditionalIncludeDirectories,
+ %(AdditionalIncludeDirectories));
+}
clOptions.AddDefines(configDefines.c_str());
clOptions.SetConfiguration((*config).c_str());
clOptions.OutputAdditionalOptions(*this-BuildFileStream, , );
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e30e4a83729c9b038b252e0a004e9b5af31c8fc3
commit e30e4a83729c9b038b252e0a004e9b5af31c8fc3
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Aug 22 09:33:58 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Aug 22 09:33:58 2014 -0400
Help: Add notes for topic 'vs-windows-apps'
diff --git a/Help/release/dev/vs-windows-apps.rst
b/Help/release/dev/vs-windows-apps.rst
new file mode 100644
index 000..63dae28
--- /dev/null
+++ b/Help/release/dev/vs-windows-apps.rst
@@ -0,0 +1,6 @@
+vs-windows-apps
+---
+
+* The :prop_tgt:`VS_WINRT_COMPONENT` target property was created to
+ tell Visual Studio generators to compile a shared library as a
+ Windows Runtime (WinRT) component.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=97a900623eb87fcc64f6dfc78985bc813f1669ee
commit 97a900623eb87fcc64f6dfc78985bc813f1669ee
Author: Brad King brad.k...@kitware.com
AuthorDate: Fri Aug 22 09:27:00 2014 -0400
Commit: Brad King brad.k...@kitware.com
CommitDate: Fri Aug 22 09:32:24 2014 -0400
VS: Do not compile C sources as WinRT (#15100)
The MSVC /ZW flag is valid only for C++ sources. Whenever we enable
CompileAsWinRT for the whole target, disable it for all C sources.
Update the documentation of VS_WINRT_COMPONENT to drop the statement
about undefined behavior for non-C++ sources, because it is now
defined as expected.
diff --git a/Help/prop_tgt/VS_WINRT_COMPONENT.rst
b/Help/prop_tgt/VS_WINRT_COMPONENT.rst
index a017f0e..e160bd6 100644
--- a/Help/prop_tgt/VS_WINRT_COMPONENT.rst
+++ b/Help/prop_tgt/VS_WINRT_COMPONENT.rst
@@ -7,8 +7,5 @@ For ``SHARED`` and ``MODULE`` libraries, this also defines the
``_WINRT_DLL`` preprocessor macro.
.. note::
- Behavior is not defined for targets with source files that compile as
- any language other than ``CXX``.
-
Currently this is implemented only by Visual Studio generators.
Support may be added to other generators in the future.
diff --git a/Source/cmVisualStudio10TargetGenerator.cxx
b/Source/cmVisualStudio10TargetGenerator.cxx
index a1dd7ab..6f1fe52 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -159,6 +159,7 @@ cmVisualStudio10TargetGenerator(cmTarget* target,
this-GUID = this-GlobalGenerator-GetGUID(this-Name.c_str());
this-Platform = gg-GetPlatformName();
this-MSTools = true;
+ this-TargetCompileAsWinRT = false;
this-BuildFileStream = 0;
this-IsMissingFiles = false;
this-DefaultArtifactDir =
@@ -1414,6 +1415,7 @@ bool
cmVisualStudio10TargetGenerator::OutputSourceSpecificFlags(
compileAs = CompileAsC;
}
}
+ bool noWinRT = this-TargetCompileAsWinRT lang == C;
bool hasFlags = false;
// for the first time we need a new line if there is something
// produced here.
@@ -1447,7 +1449,7 @@ bool
[Cmake-commits] CMake branch, master, updated. v3.0.1-1754-g8c30014
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 8c30014982345567b80ec0dad6bd9eb40dfda505 (commit) via cbd1d42b34bf83ca24de1b98c5963a2941206300 (commit) via 0f8522a6c9c00afc67c367de1e1c3f601f1996e9 (commit) via a43f44000d12c1357eeed04e5a02d11236730dfa (commit) via df3b007d7f904f8de5877f3e05b629239af7220a (commit) via e872744990f48777a1f1cebc791911363515092d (commit) via 0271a5f9ba3a8aa2b2e0a7d94a53ad3f9bb52a00 (commit) via 1d662e4806364172ebf76099c2d016efd414c74a (commit) via 4f6940df8c69053b4451056ebf3ebdc8f97bf356 (commit) via d7866c52c9fc7f28990337a965e8d9e6652b0ac5 (commit) via 0374abdb18135bfb9f1b88c8f6be17c160fb8b4a (commit) via 5b0a46e1c93f99c8ba5fadbc3224a3721d95aa64 (commit) via 802dbe52399dd2330020b94d12e594b46f85e70a (commit) from b4d3e7a7b0b4b9bdff55249633d902a35f26c02a (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=8c30014982345567b80ec0dad6bd9eb40dfda505 commit 8c30014982345567b80ec0dad6bd9eb40dfda505 Merge: b4d3e7a cbd1d42 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 22 10:37:55 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Aug 22 10:37:55 2014 -0400 Merge topic 'vs-masm' cbd1d42b Help: Add notes for topic 'vs-masm' 0f8522a6 VS: Add MASM support to VS 8 and 9 (#8170, #14984) a43f4400 VS: Move internal MasmEnabled member up to VS 7 generator df3b007d VS: Add test for MASM support e8727449 VS: Populate MASM tool build settings in .vcxproj files 0271a5f9 VS: Manually fix MASM flag table entries 1d662e48 VS: Generate MASM flag tables from MSBuild tool files 4f6940df VS: Fix ASM_MASM support in VS = 10 d7866c52 ASM_MASM: Fix selection of ml64 0374abdb ASM_MASM: Add preprocessor definitions to compile lines 5b0a46e1 ASM_MASM: Do not require compiler to be a full path 802dbe52 cmLocalVisualStudio7Generator: Rename local 'lang' var --- Summary of changes: Help/release/dev/vs-masm.rst |5 ++ Modules/CMakeASM_MASMInformation.cmake |2 +- Modules/CMakeDetermineASM_MASMCompiler.cmake |3 +- Source/cmGlobalGenerator.cxx |3 +- Source/cmGlobalVisualStudio10Generator.cxx | 10 --- Source/cmGlobalVisualStudio10Generator.h |4 -- Source/cmGlobalVisualStudio7Generator.cxx|1 + Source/cmGlobalVisualStudio7Generator.h |4 ++ Source/cmGlobalVisualStudio8Generator.cxx|8 +++ Source/cmLocalVisualStudio7Generator.cxx | 57 ++- Source/cmVS10MASMFlagTable.h | 96 ++ Source/cmVS11MASMFlagTable.h | 96 ++ Source/cmVS12MASMFlagTable.h | 96 ++ Source/cmVS14MASMFlagTable.h | 96 ++ Source/cmVisualStudio10TargetGenerator.cxx | 94 - Source/cmVisualStudio10TargetGenerator.h |6 ++ Source/cmVisualStudioGeneratorOptions.h |1 + Tests/CMakeLists.txt |8 +++ Tests/VSMASM/CMakeLists.txt | 10 +++ Tests/VSMASM/foo.asm |7 ++ Tests/VSMASM/include/foo-proc.asm|4 ++ Tests/VSMASM/main.c |2 + 22 files changed, 592 insertions(+), 21 deletions(-) create mode 100644 Help/release/dev/vs-masm.rst create mode 100644 Source/cmVS10MASMFlagTable.h create mode 100644 Source/cmVS11MASMFlagTable.h create mode 100644 Source/cmVS12MASMFlagTable.h create mode 100644 Source/cmVS14MASMFlagTable.h create mode 100644 Tests/VSMASM/CMakeLists.txt create mode 100644 Tests/VSMASM/foo.asm create mode 100644 Tests/VSMASM/include/foo-proc.asm create mode 100644 Tests/VSMASM/main.c hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.1-1741-gb4d3e7a
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 b4d3e7a7b0b4b9bdff55249633d902a35f26c02a (commit) via 204070068def4e96a9207444c445225ee94bf16c (commit) from 61dd8d84d953eb7ff8f5ac437542bb8aae289353 (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=b4d3e7a7b0b4b9bdff55249633d902a35f26c02a commit b4d3e7a7b0b4b9bdff55249633d902a35f26c02a Merge: 61dd8d8 2040700 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 22 10:37:53 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Aug 22 10:37:53 2014 -0400 Merge topic 'FindXerces' 20407006 FindXerces: New module to find Apache Xerces-C++ --- Summary of changes: Help/manual/cmake-modules.7.rst |1 + Help/module/FindXerces.rst |1 + Modules/FindXerces.cmake| 85 +++ 3 files changed, 87 insertions(+) create mode 100644 Help/module/FindXerces.rst create mode 100644 Modules/FindXerces.cmake hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, master, updated. v3.0.1-1739-g61dd8d8
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 61dd8d84d953eb7ff8f5ac437542bb8aae289353 (commit) via 050caef3aa0ab47914423dd7346a52b559d703bb (commit) from fae23fec670c6d94ba562cd4821106f25490bde5 (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=61dd8d84d953eb7ff8f5ac437542bb8aae289353 commit 61dd8d84d953eb7ff8f5ac437542bb8aae289353 Merge: fae23fe 050caef Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 22 10:37:51 2014 -0400 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Fri Aug 22 10:37:51 2014 -0400 Merge topic 'FindIce' 050caef3 FindIce: New module to find ZeroC Ice --- Summary of changes: Help/manual/cmake-modules.7.rst |1 + Help/module/FindIce.rst |1 + Modules/FindIce.cmake | 396 +++ 3 files changed, 398 insertions(+) create mode 100644 Help/module/FindIce.rst create mode 100644 Modules/FindIce.cmake hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.1-5018-g591c50c
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 591c50c5e7b9ce26fd7064fa75a965ae5ad15076 (commit) via 8c30014982345567b80ec0dad6bd9eb40dfda505 (commit) via b4d3e7a7b0b4b9bdff55249633d902a35f26c02a (commit) via 61dd8d84d953eb7ff8f5ac437542bb8aae289353 (commit) via fae23fec670c6d94ba562cd4821106f25490bde5 (commit) from 5c9b7cdd52158b5255a3ad204a88a11c528db33f (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=591c50c5e7b9ce26fd7064fa75a965ae5ad15076 commit 591c50c5e7b9ce26fd7064fa75a965ae5ad15076 Merge: 5c9b7cd 8c30014 Author: Brad King brad.k...@kitware.com AuthorDate: Fri Aug 22 10:40:12 2014 -0400 Commit: Brad King brad.k...@kitware.com CommitDate: Fri Aug 22 10:40:12 2014 -0400 Merge branch 'master' into next --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v3.0.1-5020-g4105529
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 4105529cbaaff25399714dab2e458d8e32b73a34 (commit)
via e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4 (commit)
from 591c50c5e7b9ce26fd7064fa75a965ae5ad15076 (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=4105529cbaaff25399714dab2e458d8e32b73a34
commit 4105529cbaaff25399714dab2e458d8e32b73a34
Merge: 591c50c e6fa6e6
Author: CMake Topic Stage kwro...@kitware.com
AuthorDate: Fri Aug 22 13:27:46 2014 -0400
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Fri Aug 22 13:27:46 2014 -0400
Merge topic 'wxWidgets-cflags' into next
e6fa6e60 UsewxWidgets: CFLAGS are expected to be a string here, not a list.
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4
commit e6fa6e60f6330ddf60294a0d9a6ed4cb3f27d4c4
Author: Richard M. Shaw hobbes1...@gmail.com
AuthorDate: Fri Aug 22 10:27:48 2014 -0500
Commit: Richard M. Shaw hobbes1...@gmail.com
CommitDate: Fri Aug 22 10:27:48 2014 -0500
UsewxWidgets: CFLAGS are expected to be a string here, not a list.
diff --git a/Modules/UsewxWidgets.cmake b/Modules/UsewxWidgets.cmake
index f2f260d..b3633a6 100644
--- a/Modules/UsewxWidgets.cmake
+++ b/Modules/UsewxWidgets.cmake
@@ -88,8 +88,11 @@ if (wxWidgets_FOUND)
endif()
if (wxWidgets_CXX_FLAGS)
-set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS})
-MSG(wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS})
+# Flags are expected to be a string here, not a list.
+string(REPLACE ; wxWidgets_CXX_FLAGS_str ${wxWidgets_CXX_FLAGS})
+set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} ${wxWidgets_CXX_FLAGS_str})
+MSG(wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS_str})
+unset(wxWidgets_CXX_FLAGS_str)
endif()
# DEPRECATED JW
---
Summary of changes:
Modules/UsewxWidgets.cmake |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits
