[Cmake-commits] CMake branch, master, updated. v3.6.1-877-g21ace9d

_VERSION_MINOR 6) -set(CMake_VERSION_PATCH 20160906) +set(CMake_VERSION_PATCH 20160907) #set(CMake_VERSION_RC 1) --- Summary of changes: Source/CMakeVersion.cmake |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) hooks/

[CMake] How to codesign .msi from WIX/CPack?

I'm finally trying the WIX/CPack MSI generator. Pretty nice! One thing I need to do is instruct the build process to codesign via signtool.exe. I've managed to figure out how to codesign my .exe via a POST_BUILD add_custom_command step. But now I would like to make sure the .msi that gets

Re: [cmake-developers] targets with the same name as their enclosing directory can't be built when in that directory.

Ok, thanks Brad On 5 September 2016 at 22:42, Brad King wrote: > On 09/05/2016 04:22 AM, Steve Lorimer wrote: > > $ cat src/foo/foobar/CMakeLists.txt > > add_executable(foobar main.cpp) > > However, if I am in the build/foo directory, then nothing happens > > if I "make

[CMake] add_custom_command dependencies from file?

Hi, I need to solve problem described here: https://cmake.org/pipermail/cmake/2005-August/007091.html Basically I have test.i (swig input): %module native %include "lib.hpp" %{ #include "lib.hpp" %} swig with -M option can tell that generated by it code depend on "lib.hpp", but how I can

Re: [cmake-developers] [patch] Expose GNUInstallDirs absolute path algorithm

On 30/08/2016 14:53, Brad King wrote: On 08/28/2016 01:51 PM, Roger Leigh wrote: The macro name might need adjusting The idea looks fine to me. Typically we name module-provided APIs with the module name. How about "GNUInstallDirs_get_absolute_install_dir"? I'm also open to other

[Cmake-commits] CMake branch, next, updated. v3.6.1-1827-gcb44094

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 cb44094bc5b30993d00e5bea055a02323b6dbee5 (commit) via

Re: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/"

Thank you On Tue, Sep 6, 2016 at 3:24 PM, Brad King wrote: > On 09/06/2016 03:00 PM, Ben Keller wrote: >> The workaround we are using for this currently is to compile a >> modified version of cmake that appends the following cmake code below >> the get_filename_component

[Cmake-commits] CMake branch, next, updated. v3.6.1-1825-g45c6d45

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 45c6d45ad795580eb861ca13b4d81f8f6d35943b (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1823-g87a9ffc

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 87a9ffca5fca9f6098e6098060b762a20a630a0c (commit) via

Re: [cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/"

On 09/06/2016 03:00 PM, Ben Keller wrote: > The workaround we are using for this currently is to compile a > modified version of cmake that appends the following cmake code below > the get_filename_component stanza in Targets.cmake: > > if("${_IMPORT_PREFIX}" STREQUAL "/") > set(_IMPORT_PREFIX

Re: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie

On 09/06/2016 02:39 PM, Cristian Adam wrote: > Who should have noticed that the two object files were empty and try a > new compilation? CMake or make? Nothing. This is not a failure case that we expect to be handled. The .o files exist with a timestamp newer than their dependencies, so the

[cmake-developers] Target's IMPORTED_LOCATION_* when CMAKE_INSTALL_PREFIX or CPACK_PACKAGING_INSTALL_PREFIX is "/"

CMake version 3.5.0 When exporting from a project (with install(EXPORT ...)), theTargets.cmake file contains logic for computing the _IMPORT_PREFIX. This _IMPORT_PREFIX is then used in the Targets-.cmake file to generate the IMPORTED_LOCATION_. The generation appears to be accomplished by

Re: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie

On 06-Sep-16 14:26, Brad King wrote: On 09/05/2016 04:39 PM, Cristian Adam wrote: On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote: Something goes wrong with finding some of the symbols in it, such as some from `json_value.cpp`. $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a json_reader.cpp.o

[CMake] Job Posting: Software Developer at Kitware

Folks, I wanted to draw your attention to this job posting: https://www.smartrecruiters.com/kitware/90427842-software-developer The posting itself is quite general and targets multiple teams, so I figured I'd give a few more details on what our team is looking for. We are the VTK, ParaView,

Re: [CMake] works when I build using XCode, but not with CMake makefile

Peter, In XCode I have this list of "settings" that includes "Other Linker Flags" that I have set to "-lmysqlclient -lpthread -lm -lz" and "Other C++ Flags" that I have set to "-L/Applications/MAMP/Library/lib -lmysqlclient -lpthread -lz" Maybe these explain why things work when I build with

[Cmake-commits] CMake branch, next, updated. v3.6.1-1819-gea86f38

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 ea86f387bd68596159f38b18863072769cf3df58 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1817-gce7f0cb

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 ce7f0cbce58b4688991df6db0e00b93b53d2 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1815-g345e669

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 345e669b0663a23876c815d46463ea90685bd110 (commit) via

Re: [cmake-developers] PATCH: Bugfix for WIX support

On 06.09.2016 17:19, Stuermer, Michael SP/HZA-ZSEP wrote: I checked everything on our project. Works as expected so far. I had to add our CSharp patch(es) on top, so this is not a pure WIX feature test, but I think it's good to go. Thanks I reformatted, squashed and merged to "next" for

[Cmake-commits] CMake branch, next, updated. v3.6.1-1813-gd7cc684

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 d7cc6846e9bfce3f59161ee1485b181039276d6a (commit) via

Re: [cmake-developers] PATCH: Bugfix for WIX support

> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, September 06, 2016 4:28 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: Bugfix for WIX support > > On 09/06/2016 03:45 PM, Nils Gladitz wrote: > >

Re: [cmake-developers] PATCH: Bugfix for WIX support

On 09/06/2016 03:45 PM, Nils Gladitz wrote: https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=fe20015b13d6ccf10d99ff9b3d8f68919164fcf8 Please verify that I haven't broken anything. I broke writing of WIX include files. Should be fixed now:

[Cmake-commits] CMake branch, next, updated. v3.6.1-1811-g2465396

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 246539626a1dc8558202bd0b9a343b3e0af1f426 (commit) via

Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

> -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, September 06, 2016 3:50 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: add custom xmlns namespaces into > generated .wxs sources > > On 09/06/2016

Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

On 09/06/2016 03:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: Hm, I don't see how I can add a namespace before my patch fragment. If I want to use some element from let's say UtilExtension, I need to add the xmlns:util="http://schemas.microsoft.com/wix/UtilExtension; attribute in some parent

Re: [cmake-developers] PATCH: Bugfix for WIX support

On 09/06/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote: The generated guid values where not set correctly everywhere. This could lead to WIX build errors when using the CPACK_WIX_SKIP_PROGRAM_FOLDER option. Thanks. I modified the patch to work without the global/public

Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

Wow, thanks for the fast answer! > -Original Message- > From: Nils Gladitz [mailto:nilsglad...@gmail.com] > Sent: Tuesday, September 06, 2016 2:29 PM > To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers > Subject: Re: [cmake-developers] PATCH: add custom xmlns namespaces into > generated

[Cmake-commits] CMake branch, next, updated. v3.6.1-1808-gb1590ed

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 b1590ed97f354ba39106a56656fd5829395a0fdf (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1806-g85ce7bb

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 85ce7bb6a15ad2d2b13635c04806ed62b2a1c32e (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-874-g9109ba4

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 9109ba434782a3514f1bc6a5fd3c063d231008f2 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-870-gcdc911d

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 cdc911dc53bca22ca56acf2b9a4a0d69e3120c9a (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-868-g19255a3

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 19255a3516e230da77b18c051d89012bcabcd254 (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-864-g933fc4a

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 933fc4ac4708b79c23b4bb1a6c829af4efca7efa (commit) via

[Cmake-commits] CMake branch, master, updated. v3.6.1-866-geb226b3

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 eb226b366f40da2d284bb60d57c2d8bcb85de607 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1799-gf06dd2a

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 f06dd2a0451d2ad6546a1be7894a27f901a12577 (commit) via

[Cmake-commits] CMake branch, next, updated. v3.6.1-1797-gc5ad71b

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 c5ad71bf6fb6db3530c060cd1d741c664b8e601a (commit) via

Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

On 09/06/2016 01:32 PM, Stuermer, Michael SP/HZA-ZSEP wrote: best regards, Michael Can you elaborate your use case for the patch? I assume this if for custom patch fragments? In that context wouldn't it suffice to add the namespace declarations to the elements that need them (in the patch

Re: [cmake-developers] Compiling CMake 3.6.1 fails on Raspbian Jessie

On 09/05/2016 04:39 PM, Cristian Adam wrote: > On Mon, Sep 5, 2016 at 10:33 PM, Brad King wrote: >> Something goes wrong with finding some of the symbols in it, >> such as some from `json_value.cpp`. > > $ ar t Utilities/cmjsoncpp/libcmjsoncpp.a > json_reader.cpp.o > json_value.cpp.o >

Re: [CMake] works when I build using XCode, but not with CMake makefile

Aaron, it's about the way that you compile your binary and link libmysqlclient into it. I guess (@all: please correct me if I am wrong) as I don't know how you use cmake to build your libraries/binaries, that you don't set the rpath of libmysqlclient inside your binary. Doing so will ensure

[cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

best regards, Michael 0002-added-support-for-custom-WIX-namespaces-in-generated.patch Description: 0002-added-support-for-custom-WIX-namespaces-in-generated.patch -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

[cmake-developers] PATCH: Bugfix for WIX support

The generated guid values where not set correctly everywhere. This could lead to WIX build errors when using the CPACK_WIX_SKIP_PROGRAM_FOLDER option. Viele Grüße Michael Stürmer    SZ. Prozessdatenverarbeitung SP/HZA-ZSEP  Tel. +499132 82-86350  Mobil.: +49(171)6860010

Re: [CMake] works when I build using XCode, but not with CMake makefile

Hi Mr. Cotton ;), is the location of libmysqlclient* available through DYLD_LIBRARY_PATH at runtime of your code? Best, P On 09/06/2016 10:56 AM, Cotton Candy wrote: Hi, I have a project that I originally coded up using XCode. It builds and runs just fine using XCode. Now I have tried to set

[CMake] works when I build using XCode, but not with CMake makefile

Hi, I have a project that I originally coded up using XCode. It builds and runs just fine using XCode. Now I have tried to set up the same project using CMake to generate a makefile. The project builds 100% without any errors using 'make', but the resulting code doesn't work. I get error: dyld: