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

[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-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

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).

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,

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

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).

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

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