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

[Dave Gittins]

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 but find something on
StackOverflow (which may or may not be accurate), and they will stay like
that even if new forms are available. That's what I observe in the field.

If you explain in docs that they are deprecated forms, those developers
will know what they actually do and that they are deprecated, and many will
replace with the new form.

I believe those are your choices basically; I am really hoping you choose
the latter!

Dave
On 6 Jul 2016 06:31, "Brad King"  wrote:

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 -H/-B (like confusing with --help/no spaces
> between -H and ) I can take a look. Otherwise I'm
> not interested (usually it means that the improvement will be abandoned).

The conflict with the plain `-H` help option is another reason to
keep these options private.  I've outlined what is an acceptable
path to offer public options for this workflow.  If anyone wants
to do that then great.  Otherwise the status quo will persist.

-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] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

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 internal CMake module with no 
detail description how it can be fixed. My point is that if it will work 
in most cases then why not? Most users will not even notice this.





If something bad will happen user always can use DOWNLOAD_NAME.

Example of the test that will fail with current version but works
fine with default name:

 URL "http://tinyurl.com/jn86pmc;

In that case one can just use DOWNLOAD_NAME.  Auto-extraction of
the filename from the URL is a convenience for a common case, but
in principle DOWNLOAD_NAME could always be used.
The problem with DOWNLOAD_NAME is about generalizing code. If I have 100 
ExternalProject_Add commands with such URLs then I have to add 100 
DOWNLOAD_NAME. In my case I have a bunch of templates for 
ExternalProject_Add and to introduce this feature either I have:
* test URL for the pattern in similar way CMake do and predict the fact 
that CMake will fail to extract name (not stable, what if CMake logic 
changed? DRY violation)
* force some name unconditionally like archive.tar (most of the projects 
works fine and now for no reason archives will have another names)
* add about 20-30 lines of code to core modules, for each 
ExternalProject_Add template add parsing logic and 1 line for each 
package version declaration on user side


And all this without introducing any useful features, just to suppress 
CMake error for 0.01% of cases.


Anyway I've found workaround that I will use for such URLs. According to 
my tests most of the servers ignore fragments in URL and CMake can 
extract name from them. E.g. this works:


   cmake_minimum_required(VERSION 3.5)

   include(ExternalProject)

   ExternalProject_Add(
foo
URL "http://tinyurl.com/jn86pmc#a.tar;
URL_HASH SHA1=9c29c30fff99b7c1479b2e9d4926dcc3f8d364e0
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
   )

Ruslo
-- 

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] [patch] Document -H and -B

[Brad King]

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 -H/-B (like confusing with --help/no spaces 
> between -H and ) I can take a look. Otherwise I'm 
> not interested (usually it means that the improvement will be abandoned).

The conflict with the plain `-H` help option is another reason to
keep these options private.  I've outlined what is an acceptable
path to offer public options for this workflow.  If anyone wants
to do that then great.  Otherwise the status quo will persist.

-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] [patch] One more pattern for extracting file name from URL

[Brad King]

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.
> 
> Example of the test that will fail with current version but works
> fine with default name:
> 
> URL "http://tinyurl.com/jn86pmc;

In that case one can just use DOWNLOAD_NAME.  Auto-extraction of
the filename from the URL is a convenience for a common case, but
in principle DOWNLOAD_NAME could always be used.

-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] Fix bug in CPack IFW Promoting Updates repository replacement

[Konstantin Podsvirov]

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
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7a30fa1a
>
>> Changes are best to send to a mailing list or use your networks?
>
> Either is fine. We're still experimenting with the Networks
> workflow so it is not documented in the CONTRIBUTING.rst yet.

I apologize that sometimes there are persistent, but thank you so much for your 
feedback and applying my changes.

The theme of integration and CMake QtIFW quite new and deals with both 
technologies.

I get good feedback from CMake and try to influence the development of QtIFW.

The project QtIFW included in the Qt infrastructure and make changes to it is 
not so simple. But I'm trying. Here's my first change (it is still pending):

https://codereview.qt-project.org/#/c/163220

I want to go further and to provide CMakeLists.txt to build the QtIFW.
I'm working on this theme in a topic branch "topic-cmake-project" on your 
server:

http://git.podsvirov.pro/?p=qt/qtifw.git;a=shortlog;h=refs/heads/topic-cmake-project

It is very dirty now, but there are already some results.
The project QtIFW for normal operation requires linking with the static version 
of the Qt library. This is not standard practice and could have a positive 
impact on the detection and correction of errors in this case.

I hope that this topic will ever be merged with the project QtIFW.

--
Regards,
Konstantin Podsvirov
-- 

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] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

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 commit:

  ExternalProject: Match filenames in URLs with query strings and anchors
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=57c337e2

Thanks,
-Brad

Works fine on my tests. However I still vote for using default value for 
'fname' instead of FATAL_ERROR. If something bad will happen user always 
can use DOWNLOAD_NAME.


Example of the test that will fail with current version but works fine 
with default name:


   cmake_minimum_required(VERSION 3.5)

   include(ExternalProject)

   ExternalProject_Add(
foo
URL "http://tinyurl.com/jn86pmc;
URL_HASH SHA1=9c29c30fff99b7c1479b2e9d4926dcc3f8d364e0
CONFIGURE_COMMAND ""
BUILD_COMMAND ""
INSTALL_COMMAND ""
   )

Ruslo
-- 

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] Fix bug in CPack IFW Promoting Updates repository replacement

[Brad King]

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 mailing list or use your gitlab?

Either is fine.  We're still experimenting with the GitLab
workflow so it is not documented in CONTRIBUTING.rst yet.

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

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

[Konstantin Podsvirov]

 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 CPackIFW. The patch is attached.

I read the wrong documentation for QtIFW 
(https://bugreports.qt.io/browse/QTIFW-873) and made the wrong generation.
I conducted a series of tests and now everything should work correctly.

I have a household question:
Changes are best to send to a mailing list or use your gitlab?
 sending message  

Regards,
Konstantin Podsvirov
From e52011d61867db107c3437d7e55e02bcdc555f41 Mon Sep 17 00:00:00 2001
From: Konstantin Podsvirov 
Date: Tue, 5 Jul 2016 22:30:12 +0300
Subject: [PATCH 3/3] CPackIFW: Fixed attributes for repository replace

---
 Source/CPack/IFW/cmCPackIFWRepository.cxx | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Source/CPack/IFW/cmCPackIFWRepository.cxx b/Source/CPack/IFW/cmCPackIFWRepository.cxx
index ee6d5e5..fcb1c77 100644
--- a/Source/CPack/IFW/cmCPackIFWRepository.cxx
+++ b/Source/CPack/IFW/cmCPackIFWRepository.cxx
@@ -299,8 +299,8 @@ void cmCPackIFWRepository::WriteRepositoryUpdate(cmXMLWriter& xout)
   if (Update == Add || Update == Remove) {
 xout.Attribute("url", Url);
   } else if (Update == Replace) {
-xout.Attribute("oldurl", OldUrl);
-xout.Attribute("newurl", NewUrl);
+xout.Attribute("oldUrl", OldUrl);
+xout.Attribute("newUrl", NewUrl);
   }
   // Enabled
   if (!Enabled.empty()) {
-- 
2.8.3.windows.1

-- 

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] [patch] One more pattern for extracting file name from URL

[Ben Boeckel]

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). This would also be
> > useful for things other than ExternalProject.
> 
> This may be a reasonable idea for the future but we are getting
> way off from the original patch here.

https://gitlab.kitware.com/cmake/cmake/issues/16187

--Ben
-- 

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] [patch] One more pattern for extracting file name from URL

[Ben Boeckel]

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, it was used internally, unpack archive for 
> you and you can do what you want with **unpacked** sources. Anyway you 
> can always force the name with |DOWNLOAD_NAME.|

I'm more considering the case of using the files as they exist on the
disk for other purposes, not necessarily through code (which probably
should be using `cmake -E tar`). For example, I will do:

  - tar xf $tarball.tar.gz
  - cp -a $tarball $tarball.to-patch
  - $edit .to-patch
  - diff -U5 -r $tarball $tarball.to-patch

to create patches for ExternalProject tarballs we use.

--Ben
-- 

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] Green Hills MULTI Generator Recommendations

[Brad King]

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 appropriate
> CMAKE__COMPILER variables in the toolchain file?

The latter for now.

> If the generator should provide a list of known compiler names,
> would CMake's -A option be the appropriate way to specify the target
> processor's platform?

No, the -A option is for when the underlying build system (e.g. VS IDE)
has declarative options to specify things like that.

> 2. Is there a way in a toolchain file or on the command line to specify
> the directory where CMake should look for the compiler executables?

The find_program command is used for some generators.  I don't recall
if GHS does its own thing or not.  One could add it to ENV{PATH} or
see the documentation of the find_program command for how it searches.

> 3. Is there a way to specify the make executable full path in the toolchain 
> file?

Try making it a cache entry:

 set(CMAKE_MAKE_PROGRAM /path/to/gbuild CACHE FILEPATH "path to gbuild")

Note that toolchain files are meant to be produced locally and
hard-coded for a local machine, so such content is appropriate.

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] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

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 is not my go-to tool for extracting files though (and similarly
for others I imagine), so running `tar xf archive.tar` and getting an
error because it is actually a .tar.gz (or even a .zip) file is not
nice.
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, it was used internally, unpack archive for 
you and you can do what you want with **unpacked** sources. Anyway you 
can always force the name with |DOWNLOAD_NAME.|



So even if it seems that archive name is `|archive.tar.gz` it should be
downloaded to
`||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So
I think it's easily can be file with another extension.|

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.

--Ben

Good idea, I'll be happy to see this feature in future CMake releases.

Ruslo
-- 

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] [patch] One more pattern for extracting file name from URL

[Brad King]

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.

This may be a reasonable idea for the future but we are getting
way off from the original patch here.

I will likely commit something from this thread when I get a chance
to review it.

-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] [patch] One more pattern for extracting file name from URL

[Ben Boeckel]

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 extracting files though (and similarly
for others I imagine), so running `tar xf archive.tar` and getting an
error because it is actually a .tar.gz (or even a .zip) file is not
nice.

> So even if it seems that archive name is `|archive.tar.gz` it should be 
> downloaded to 
> `||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So 
> I think it's easily can be file with another extension.|

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.

--Ben
-- 

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] [PATCH v2] Improve encoding handling on Windows

[Brad King]

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 next round please split out refactoring changes like
converting clients to the alternative GetEnv signature into preceding
commits.  That will simplify review and allow many hunks to be
integrated even if other changes need more revisions.

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] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

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 then it is user's responsibility I think. 
For example GitHub releases goes without name of the project so both:


* https://github.com/ruslo/polly/archive/v0.10.1.tar.gz
* https://github.com/ruslo/hunter/archive/v0.10.1.tar.gz

will be downloaded to v0.10.1.tar.gz - this filename extracted from URL 
by CMake. In general patch made in a code branch where was FATAL_ERROR 
before, so it doesn't affect backward compatibility.




Though I'm partial to keeping the extension still; if I need to add a
patch to a project, it'd be nice if the extension weren't a lie when I
go to extract the tarball.
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).


Also note that in fact name of the file extracted from URL can differ 
from real:

|
> curl --head 
https://gitlab.com/gitlab-org/gitlab-ce/repository/archive.tar.gz\?ref\=v8.9.3 
| grep file
Content-Disposition: attachment; 
filename="gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz"|


So even if it seems that archive name is `|archive.tar.gz` it should be 
downloaded to 
`||gitlab-ce-v8.9.3-5e546d9b4728fc9c9623992a678cbea9eb2098f1.tar.gz`. So 
I think it's easily can be file with another extension.|


Ruslo
-- 

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] [patch] One more pattern for extracting file name from URL

[Ben Boeckel]

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
patch to a project, it'd be nice if the extension weren't a lie when I
go to extract the tarball.

--Ben
-- 

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] [patch] One more pattern for extracting file name from URL

[Ben Boeckel]

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 _ep_write_extractfile_script function)
> +  set(fname "archive.tar")

Is this going to cause multiple tarball downloads to overwrite each
other in the download cache directory?

--Ben
-- 

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] [patch] One more pattern for extracting file name from URL

[Ruslan Baratov via cmake-developers]

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

On 01-Jul-16 15:01, Ruslan Baratov via cmake-developers wrote:

Hi,

With attached patch it's possible to extract name from URLs like 
'https://.../archive.tar.gz?a=x=y'.


Ruslo 



>From 5284eedbd1b038aab2eab73252eb41914afb14e1 Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Tue, 5 Jul 2016 16:17:12 +0300
Subject: [PATCH] Use default filename if extracting from URL failed

---
 Modules/ExternalProject.cmake | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 2ff18fc..4c35c8b 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1880,7 +1880,10 @@ function(_ep_add_download_command name)
 if (no_extract)
   get_filename_component(fname "${url}" NAME)
 elseif(NOT "${fname}" MATCHES "(\\.|=)(7z|tar|tar\\.bz2|tar\\.gz|tar\\.xz|tbz2|tgz|txz|zip)$")
-  message(FATAL_ERROR "Could not extract tarball filename from url:\n  ${url}")
+  # 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 _ep_write_extractfile_script function)
+  set(fname "archive.tar")
 endif()
 string(REPLACE ";" "-" fname "${fname}")
 set(file ${download_dir}/${fname})
-- 
1.9.1

-- 

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] [patch] Document -H and -B

[Ruslan Baratov via cmake-developers]

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 improve 
the current behavior of -H/-B (like confusing with --help/no spaces 
between -H and ) I can take a look. Otherwise I'm 
not interested (usually it means that the improvement will be abandoned).


Ruslo
--

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