Re: [CMake] C header file cross dependency

Hi @all, I've finally found a solution to the problem. My solution is here: https://github.com/martinwag/test_cmake/tree/master What I did: - remove "OBJECT" library targets as they do not work in combination with interface libraries - added one install target per library, so I get one

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-313-g7d3fe19

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

Re: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED

Ack - sorry. s/INTERFACE_LINK_LIBRARIES/IMPORTED_LOCATION/cg. INTERFACE_LINK_LIBRARIES I guess would be a completely valid property to set on an add_library(foo INTERFACE) target. But IMPORTED_LOCATION wouldn't, right? "INTERFACE IMPORTED would then mean there is no compiled binary to be linked

Re: [CMake] Confusion over INTERFACE vs STATIC|SHARED IMPORTED vs INTERFACE IMPORTED

>From what I understand, interface libraries just don't have sources or build results. INTERFACE IMPORTED would then mean there is no compiled binary to be linked against, just as INTERFACE alone means there are no sources to create said binary from. At least, that is my understanding. > My

Re: [cmake-developers] [patch] Document -H and -B

I think we should add new normalised forms but still mention the deprecated names in the docs. You can't put the cat back in the bag - like it or not, those option names seem quite widely used. Developers will join a project and see them in use. Currently they will find no mention of them in docs

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On 05-Jul-16 23:26, Brad King wrote: On 07/05/2016 04:13 PM, Ruslan Baratov wrote: Works fine on my tests. Thanks for testing! However I still vote for using default value for 'fname' instead of FATAL_ERROR. I think that behavior would be surprising. Not such surprising as some error in

Re: [cmake-developers] [patch] Document -H and -B

On 07/05/2016 06:29 AM, Ruslan Baratov wrote: > I don't see the point of introducing new options. Developers will still > use -H/-B because it's backward compatible, well known and will work > 100% because of internal CMake testing. That said if you want to improve > the current behavior of

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On 07/05/2016 04:13 PM, Ruslan Baratov wrote: > Works fine on my tests. Thanks for testing! > However I still vote for using default value for 'fname' instead > of FATAL_ERROR. I think that behavior would be surprising. > If something bad will happen user always can use DOWNLOAD_NAME. > >

Re: [cmake-developers] Fix bug in CPack IFW Promoting Updates repository replacement

Thanks again, Brad! 05.07.2016, 22:58, "Brad King" : > On date 07/05/2016 03:39 PM, Konstantin Podsvirov wrote: >> I found a small bug in CPackIFW. The patch is attached. > > Thanks, applied: > > CPackIFW: Fix attributes for Promoting Updates repository replacement >

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On 05-Jul-16 22:03, Brad King wrote: On 07/01/2016 03:35 PM, Brad King wrote: I don't think we should duplicate the "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$" expression. The stripping of ?.* can be done earlier, or done as part of the main match. Please try this

Re: [CMake] ImageMagick Not Found with CMake

El 05/07/16 a las 15:05, Richard Kralik escribió: I am trying to install Theia-SfM (http://www.theia-sfm.org/index.html) using cmake 3.6 on Ubuntu 16.04. When trying to configure the project the output ends with Why can FindImageMagick not find convert and mogrify? My guess. Because they

[cmake-developers] Fix bug in CPack IFW Promoting Updates repository replacement

On 07/05/2016 03:39 PM, Konstantin Podsvirov wrote: > I found a small bug in CPackIFW. The patch is attached. Thanks, applied: CPackIFW: Fix attributes for Promoting Updates repository replacement https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a30fa1a > Changes are best to send to a

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-706-gfa3c295

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

[cmake-developers] Fwd: CMake | CPackIFW: Using cpack_append_list_variable_set_command (!27)

sending message 05.07.2016, 22:37, "Konstantin Podsvirov" : Thanks, Brad! I've been waiting for your answer :-) 05.07.2016, 22:30, "Brad King" : >  Thanks. I've merged this to next for testing. I found a small bug in

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-704-g97ac2ea

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-702-g6d89ece

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On Tue, Jul 05, 2016 at 13:46:06 -0400, Brad King wrote: > On 07/05/2016 01:31 PM, Ben Boeckel wrote: > > Here's another idea: add an `OUTPUT_FILE ` keyword argument to > > `file(DOWNLOAD)` to get the actual filename after content disposition > > resolution (probably similar for 30x rewrites).

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-700-g43305ef

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-698-gf6cf0b1

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-312-g8d33027

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-696-g7bb7361

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-693-g603d1e5

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-689-g351936c

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-687-gc101662

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On Tue, Jul 05, 2016 at 21:01:36 +0300, Ruslan Baratov wrote: > Well it's never too late to learn something new. Also `tar` is not > widely used on Windows so to write nice code you should convert it to > `cmake -E tar`. That the whole point of `cmake -E` feature. > I don't see the problem here,

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-685-gf5287ad

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

Re: [cmake-developers] Green Hills MULTI Generator Recommendations

On 07/02/2016 02:21 PM, Chris Bux wrote: > I am interested in using CMake with Green Hills MULTI. Adding Geoffrey Viola to Cc who implemented the current GHS support. > Should the MULTI generator provide a list of known compiler names > by architecture, or should we rely on users to set the

[CMake] ImageMagick Not Found with CMake

I am trying to install Theia-SfM (http://www.theia-sfm.org/index.html) using cmake 3.6 on Ubuntu 16.04. When trying to configure the project the output ends with -- Check for ImageMagick CMake Error at /usr/local/share/cmake-3.6/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On 05-Jul-16 20:31, Ben Boeckel wrote: On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote: Archive can be unpacked by "cmake -E tar xf" which detect type automatically as far as I understand. At least this one used internally by ExternalProject (see the testing I've made before).

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-683-g01c100d

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On 07/05/2016 01:31 PM, Ben Boeckel wrote: > Here's another idea: add an `OUTPUT_FILE ` keyword argument to > `file(DOWNLOAD)` to get the actual filename after content disposition > resolution (probably similar for 30x rewrites). This would also be > useful for things other than ExternalProject.

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On Tue, Jul 05, 2016 at 19:49:46 +0300, Ruslan Baratov wrote: > Archive can be unpacked by "cmake -E tar xf" which detect type > automatically as far as I understand. At least this one used internally > by ExternalProject (see the testing I've made before). CMake is not my go-to tool for

Re: [cmake-developers] [PATCH v2] Improve encoding handling on Windows

On 07/03/2016 09:22 AM, Dāvis Mosāns wrote: > Huge thanks for review! Will fix mentioned issues in next version of patch. > Also I'll implement this solution with std::streambuf as it's much better way > and it's actually not that much work I thought it would be. Yes, thanks Mike! Dāvis, in the

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On 05-Jul-16 18:50, Ben Boeckel wrote: On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote: By default not, goes to -prefix/src/archive.tar . Right, but if a download directory is set, this won't work. Can the project name at least be added to the name? If user are forcing directory

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On Tue, Jul 05, 2016 at 18:43:25 +0300, Ruslan Baratov wrote: > By default not, goes to -prefix/src/archive.tar . Right, but if a download directory is set, this won't work. Can the project name at least be added to the name? Though I'm partial to keeping the extension still; if I need to add a

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-310-g909048e

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

[Cmake-commits] CMake branch, master, updated. v3.6.0-rc4-308-gd169b13

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-671-g98fe585

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-662-ge78a4f0

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

[Cmake-commits] CMake branch, next, updated. v3.6.0-rc4-658-g53c8b78

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

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

On Tue, Jul 05, 2016 at 16:26:54 +0300, Ruslan Baratov via cmake-developers wrote: > + # Do not put warning message here. If everything works OK it will > + # only distract. If unpack will fail the standard name can be > found in logs. > + # (see

Re: [cmake-developers] [patch] One more pattern for extracting file name from URL

Got another idea. We can use default name like 'archive.tar'. Seems that internal type of archive determined automatically and doesn't depends on the filename. I've tried one example for each extension: 7z, tar.bz2, tar.gz, tar.xz, tbz2, tgz, txz, zip and it just works. Patch attached. Ruslo

Re: [cmake-developers] [patch] Document -H and -B

On 01-Jul-16 15:58, Brad King wrote: * Allow the form `-H -B ` with the new names. I don't see the point of introducing new options. Developers will still use -H/-B because it's backward compatible, well known and will work 100% because of internal CMake testing. That said if you want to