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

[clinton]

- On Jun 30, 2016, at 8:18 PM, Dāvis Mosāns davis...@gmail.com wrote:

> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.
> 
> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
> 
> Next, when we're outputing to console need to use wide functions.
> 
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.

...

> +#if defined(_WIN32)
> +  // Kinda hack, with MSVC (and MinGW) for some reason std::wcout
> +  // (and all other std::w*) fails once it encounters non-ASCII
> +  // string unless locale is set.
> +  // Note that even with this, seems it can't output characters
> +  // which aren't present in ANSI codepage no matter what encoding
> +  // is used for console.
> +  // Also once any character outside of ANSI codepage is tried to
> +  // be outputed then after there anymore won't be output from
> +  // any of std::w* functions.
> +  _wsetlocale(LC_ALL, L"");
> +#endif

The _wsetlocale() may be a problem.

See:
https://gitlab.kitware.com/cmake/cmake/commit/87be2e142
https://cmake.org/Bug/view.php?id=16099


> @@ -30,8 +30,23 @@ namespace @KWSYS_NAMESPACE@
>   typedef std::basic_filebuf my_base_type;
>   basic_filebuf *open(char const *s,std::ios_base::openmode mode)
>   {
> +std::wstring wstr = Encoding::ToWide(s);
> +const wchar_t *ws = wstr.c_str();
> +#if defined(_MSC_VER) && _MSC_VER >= 1400
> +const wchar_t *ss = ws;
> +#else
> +const char *ss = 0;
> +size_t length = std::wcstombs(0, ws, 0);
> +if (length != size_t(-1)) {
> +  std::vector str(length + 1);
> +  ss = str.data();
> +  std::wcstombs((char *)ss, ws, str.size());
> +} else {
> +  ss = s;
> +}
> +#endif
> return static_cast(
> -  my_base_type::open(Encoding::ToWide(s).c_str(), mode)
> +  my_base_type::open(ss, mode)
>   );

Yes.  It makes sense to convert from utf-8 to code page when we are not using 
the wide apis.
This would at least give you support for the current code page, beyond ascii.   
Beyond that, the wide functions should be used.
Which compiler are you trying to support here, which doesn't give a wide open()?


>   }
>   };
> diff --git a/Source/kwsys/ProcessWin32.c b/Source/kwsys/ProcessWin32.c
> index 2b93e69..208e725 100644
> --- a/Source/kwsys/ProcessWin32.c
> +++ b/Source/kwsys/ProcessWin32.c
> @@ -181,7 +181,7 @@ struct kwsysProcessPipeData_s
>   /* - Data managed per call to Execute - */
> 
>   /* Buffer for data read in this pipe's thread.  */
> -  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE];
> +  char DataBuffer[KWSYSPE_PIPE_BUFFER_SIZE*2];

This "*2" assumes all characters cmake sees will fit in the Basic Multilingual 
Plane.
Are we OK assuming that?
If the conversion from a code page to utf-16 results in surrogate pairs, there 
may not be enough space.


> 
>   /* The length of the data stored in the buffer.  */
>   DWORD DataLength;
> @@ -1626,6 +1626,25 @@ void kwsysProcessPipeThreadReadPipe(kwsysProcess* cp,
> kwsysProcessPipeData* td)
>   KWSYSPE_DEBUG((stderr, "read closed %d\n", td->Index));
>   }
> 
> +if (td->DataLength > 0) {
> +UINT codepage = GetConsoleCP();
> +if (!codepage) {
> +codepage = GetACP();


Can this be stored in kwsysProcessCreateInformation, and not computed ever time 
we read data?



> +}
> +if (codepage != KWSYS_ENCODING_DEFAULT_CODEPAGE) {
> +int wlength = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, NULL, 0);
> +wchar_t* wdata = malloc(wlength * sizeof(wchar_t));
> +int r = MultiByteToWideChar(codepage, 0, td->DataBuffer,
> td->DataLength, wdata, wlength);
> +if (r > 0) {
> +r = WideCharToMultiByte(KWSYS_ENCODING_DEFAULT_CODEPAGE, 0,
> wdata, wlength, td->DataBuffer, KWSYSPE_PIPE_BUFFER_SIZE * 2, NULL, NULL);
> +if (r > 0) {
> +td->DataLength = r;
> +}
> +}
> +free(wdata);
> +}
> +}

How about avoiding a malloc()/free() each time we read an array?

ProcessWin32.c already uses Encoding.h.  How about using the Encoding instead 
of 
WideCharToMultiByte(...)?  I'm fine either way.


Thanks for looking into this.
I had experimented with some of this as a next step, but didn't finish it.
Your general approach seems correct.

Clint
-- 

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 

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

[clinton]

- On Jul 1, 2016, at 8:41 AM, Mike Gelfand mike...@mikedld.com wrote:

> On 07/01/2016 05:12 PM, Ben Boeckel wrote:
>> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote:
>>> 2. change GetEnv to return std::unique_ptr which will be
>>>   automatically deleted once out of scope and we still can check if there
>>>   wasn't such env if it's empty.
>> Hrm. I'd rather use std::optional than relying on implicit nullptr
>> semantics.
> 
> Since you already have "bool SystemTools::GetEnv(const char* key,
> std::string& result)", another option would be to use it everywhere and
> maybe introduce something like "bool SystemTools::HasEnv(const char*
> key)" for those several cases where you only need to check the existence.
> 

+1

- Clint
-- 

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/01/2016 11:48 AM, Ruslan Baratov wrote:
> On 01-Jul-16 15:58, Brad King wrote:
>> Please try to structure the logic right in the if/elseif part.
>> Matching in those also sets `CMAKE_MATCH_*` variables so one
>> does not need to double-match.
> 'elseif' part try to find 'archive.tar.gz' in '${fname}', then 'string(REGEX' 
> try to match it in '${url}'. There is no reusing of 'CMAKE_MATCH_*'.

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.

>> Also, the `([^/]*)\\?.*` part of the regex should be more
>> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
> We can't have question mark ('?') in path as far as I understand, it should 
> be percent-encoded, will be |'%3F'.|||
> https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax
> https://en.wikipedia.org/wiki/Percent-encoding

In that case it won't hurt to exclude `?` and `#` from the
allowed matching.

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

[Ben Boeckel]

On Fri, Jul 01, 2016 at 18:48:41 +0300, Ruslan Baratov wrote:
> On 01-Jul-16 16:04, Ben Boeckel wrote:
> > On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:
> >> Also, the `([^/]*)\\?.*` part of the regex should be more
> >> like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
> > This should also probably skip '#' characters for URLs with anchors.
> >
> > --Ben
> 'fragement' goes after 'query' so as far as I understand it's not necessary.
> https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax

Right, but if there isn't a query part:

foo.tar.gz#some_anchor

--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] cmake -E capabilities

[Tobias Hunger]

On Do, 2016-06-30 at 15:00 -0400, Brad King wrote:
> On 06/30/2016 09:51 AM, Tobias Hunger wrote:
> > Compared to the bug report mentioned above the fields "multiconfig" and
> > "recursive" are missing. I could not figure out how to get that
> > information:-/
> 
> There is no "recursive" generator, so that does not belong in the example
> anyway.  The Makefile generator does not produce recursive makefiles:
> 
>  https://cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.
> 3F

Great, one thing less to worry about:-)

> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
> Something similar will have to be added to the generator factory APIs
> so that we can ask for this information without creating a generator.

Sorry for not knowing any better... But does it make sense to provide that
information?

I do not see why this information is need to set up a cmake project. I need two
directories and a generator. Do I need to know what the generator produces at
that point?

Once I get the project structure I have the information on the generated
configurations -- incl. their names.

Either we should have multiConfig return a list of configuration names that will
be generated or I do not see any need to have the information in the first
place.

> > I could also not yet figure out a way to retrieve information on supported
> > platforms and toolsets. At least I did get whether a generator supports
> > toolsets, but nothing similar seems to exist for the platform part.
> 
> We don't have any information on supported platforms or toolsets.
> The CMAKE_GENERATOR_PLATFORM and CMAKE_GENERATOR_TOOLSET settings
> take user-specified values and we pass them through to native tools.
> It is up to the user to provide valid values.

Looking at the code I am a bit confused:

All the generators that take a platform seem to get that set via the generator
name. E.g. there are
* "Visual Studio 10 2010",
* "Visual Studio 10 2010 Win64" and
* "Visual Studio 10 2010 IA64"
generators registered.

All these different names trigger a new generator to be created with different
DefaultPlatformName set up (even though the documentation string for the
generators reports the Win64/IA64 part as "[arch]", not platform).

Note that "Win64" gets mapped to a platform name of "x64" and "IA64" gets mapped
to "Itanium".

So far so good...


The cmake command line lets me apparently use "-A platform" to set
cmake::GeneratorPlatform. That will end up in the cache as
"CMAKE_GENERATOR_PLATFORM" (after some validation).

Generators will get that value from the cmMakefiles (where they move into via
the CMakeCache AFAICT). That information will be passed to the generator via the
SetGeneratorPlatform method, which will then override the default platform set
via the generator name.


Why can I specify the platform names in two different ways? Why do the two ways
disagree on the platform name ("Win64" vs. "x64")? Did you rename the concept
from architecture to platform at some point (or why does the documentation use
[arch] and the command line client "-A")? I guess there are interesting
compatibility considerations behind all this:-)

What is the preferred way to set up a Visual studio project nowadays? Should I
filter out the architecture specific generators in favor or using -A on the
command line or the other way around? Or do both cover completely separate use
cases?

If "-A" is the way to go, then I would like to try my hand at adding a method to
retrieve all valid platforms for a generator. CMake has a lot of code to find
those names (or hardcodes known names), so why not pass it on to the user?

So far I only looked into the visual studio generators, so I might have missed
something that blocks such a method in other generators.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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 01-Jul-16 16:04, Ben Boeckel wrote:

On Fri, Jul 01, 2016 at 08:58:16 -0400, Brad King wrote:

Also, the `([^/]*)\\?.*` part of the regex should be more
like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.

This should also probably skip '#' characters for URLs with anchors.

--Ben

'fragement' goes after 'query' so as far as I understand it's not necessary.
https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax

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

[Ruslan Baratov via cmake-developers]

On 01-Jul-16 15:58, Brad King wrote:

On 07/01/2016 08:01 AM, Ruslan Baratov via cmake-developers wrote:

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

Thanks.


  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}")
+  # Try: https://.../archive.tar.gz?a=x=y
+  string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
+  set(fname "${CMAKE_MATCH_1}")
+  if(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}")
+  endif()

Please try to structure the logic right in the if/elseif part.
Matching in those also sets `CMAKE_MATCH_*` variables so one
does not need to double-match.
'elseif' part try to find 'archive.tar.gz' in '${fname}', then 
'string(REGEX' try to match it in '${url}'. There is no reusing of 
'CMAKE_MATCH_*'.




Also, the `([^/]*)\\?.*` part of the regex should be more
like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.
We can't have question mark ('?') in path as far as I understand, it 
should be percent-encoded, will be |'%3F'.|||

https://en.wikipedia.org/wiki/Uniform_Resource_Locator#Syntax
https://en.wikipedia.org/wiki/Percent-encoding

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

[Mike Gelfand]

On 07/01/2016 05:12 PM, Ben Boeckel wrote:
> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote:
>> 2. change GetEnv to return std::unique_ptr which will be
>>   automatically deleted once out of scope and we still can check if there
>>   wasn't such env if it's empty.
> Hrm. I'd rather use std::optional than relying on implicit nullptr
> semantics.

Since you already have "bool SystemTools::GetEnv(const char* key,
std::string& result)", another option would be to use it everywhere and
maybe introduce something like "bool SystemTools::HasEnv(const char*
key)" for those several cases where you only need to check the existence.

Regards,
Mike
-- 

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

[Brad King]

On 07/01/2016 10:16 AM, Daniel Pfeifer wrote:
>> Hrm. I'd rather use std::optional than relying on implicit nullptr
>> semantics.
> 
> +1.
> 
> This class here should be renamed to cmOptional and moved to its own
> file, so it may be reused:
> http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22

The GetEnv method in question is in KWSys which has clients besides
CMake.  I'd like to avoid adding an Optional class to it or using
C++11 in it.  Please see my response in another part of this thread.

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

[Daniel Pfeifer]

On Fri, Jul 1, 2016 at 4:12 PM, Ben Boeckel  wrote:
> On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote:
>> 2. change GetEnv to return std::unique_ptr which will be
>>   automatically deleted once out of scope and we still can check if there
>>   wasn't such env if it's empty.
>
> Hrm. I'd rather use std::optional than relying on implicit nullptr
> semantics.

+1.

This class here should be renamed to cmOptional and moved to its own
file, so it may be reused:
http://public.kitware.com/gitweb?p=stage/cmake.git;a=blob;f=Source/cmArchiveWrite.h;h=f847d09b74922e800293e70c3171accb500c083c;hb=refs/heads/master#l22
-- 

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

[Ben Boeckel]

On Fri, Jul 01, 2016 at 16:44:32 +0300, Dāvis Mosāns wrote:
> 2. change GetEnv to return std::unique_ptr which will be
>   automatically deleted once out of scope and we still can check if there
>   wasn't such env if it's empty.

Hrm. I'd rather use std::optional than relying on implicit nullptr
semantics.

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

[Dāvis Mosāns]

2016-07-01 15:25 GMT+03:00 Daniel Pfeifer :

> Hi Dāvis,
>
> On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns  wrote:
> > On Windows getenv uses ANSI codepage so it needs to be encoded to
> > internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> > and encode that.
>
> Your change to the SystemTools::GetEnv function introduces memory
> leaks, since you return a pointer to a new[]-ed array.
> It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
> and provide interface compatability.
> You should probably introduce a function that returns std::string and
> uses GetEnvironmentVariableW internally.
>
>
I know about memory leak, I intentionally left it this way for first version
of patch as there are multiple ways how to implement it properly.

POSIX's getenv doesn't need to be freed, but here for Windows since we need
to encode it to internal encoding we'll be returning a new pointer.

I see two ways:

1. add SystemTools::FreeEnv which delete's if on Windows but does nothing
  otherwise;
2. change GetEnv to return std::unique_ptr which will be
  automatically deleted once out of scope and we still can check if there
  wasn't such env if it's empty.

To me 2nd option seems best.
-- 

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

[Brad King]

On 07/01/2016 08:25 AM, Daniel Pfeifer wrote:
> On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns  wrote:
>> On Windows getenv uses ANSI codepage so it needs to be encoded to
>> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
>> and encode that.

Thanks.  Clinton (in Cc) did quite a bit of work to get argv[] and
file processing to use wide character APIs on Windows.  It looks like
environment variables are next.

> Your change to the SystemTools::GetEnv function introduces memory
> leaks, since you return a pointer to a new[]-ed array.
> It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
> and provide interface compatability.

We could keep our own std::map around to own the memory and use that
to retain compatibility in the existing API.

It would be nice to also offer an alternative API that passes
ownership of the result to the caller.

> You should probably introduce a function that returns std::string and
> uses GetEnvironmentVariableW internally.

The signature also needs to allow callers to determine whether the
environment variable was set to empty or not set at all.

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] cmake -E capabilities

[Brad King]

On 07/01/2016 05:11 AM, Tobias Hunger wrote:
>> For "multiconfig", there is the cmGlobalGenerator::IsMultiConfig method.
> I do not see why this information is need to set up a cmake project. I need 
> two
> directories and a generator. Do I need to know what the generator produces at
> that point?

If we don't foresee a use case for it we don't need to add it now.  The
example given in the issue was just a quick demo IIUC and not intended to
be authoritative result of deep design thought.

> * "Visual Studio 10 2010",
> * "Visual Studio 10 2010 Win64" and
> * "Visual Studio 10 2010 IA64"
[snip]
> The cmake command line lets me apparently use "-A platform"
[snip]
> Why can I specify the platform names in two different ways? Why do
> the two ways disagree on the platform name ("Win64" vs. "x64")?

See here:

 https://cmake.org/cmake/help/v3.6/generator/Visual%20Studio%2014%202015.html

At one time the generator name was the only way.  The names were not
originally chosen to match VS's platform names and were then kept for
compatibility.  The -A/CMAKE_GENERATOR_PLATFORM approach was added
more recently to decouple the generator name from the target architecture.

> What is the preferred way to set up a Visual studio project nowadays?

The preferred way is now:

  -G "Visual Studio 10 2010" -A x64

Its usage is not widespread because it doesn't make that much difference
for x64 and the feature has only been around for a couple years.

> If "-A" is the way to go, then I would like to try my hand at adding
> a method to retrieve all valid platforms for a generator. CMake has
> a lot of code to find those names (or hardcodes known names), so why
> not pass it on to the user?

If it is reasonably straightforward to do then go for it.  That would
be nice to offer.

> So far I only looked into the visual studio generators, so I might
> have missed something that blocks such a method in other generators.

The Xcode generator supports CMAKE_GENERATOR_TOOLSET but not
CMAKE_GENERATOR_PLATFORM.  The Makefile and Ninja generators support
neither because they are expected to be run from an environment that
is already configured for a given toolchain/architecture.

-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/01/2016 08:01 AM, Ruslan Baratov via cmake-developers wrote:
> With attached patch it's possible to extract name from URLs like 
> 'https://.../archive.tar.gz?a=x=y'.

Thanks.

>  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}")
> +  # Try: https://.../archive.tar.gz?a=x=y
> +  string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
> +  set(fname "${CMAKE_MATCH_1}")
> +  if(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}")
> +  endif()

Please try to structure the logic right in the if/elseif part.
Matching in those also sets `CMAKE_MATCH_*` variables so one
does not need to double-match.

Also, the `([^/]*)\\?.*` part of the regex should be more
like `([^/?]*)\\?.*` to avoid eagerly matching early `?`.

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

[Brad King]

On 06/30/2016 05:35 PM, Dave Gittins wrote:
> I don't understand the harm of documenting the options and making
> them public.

The discussion got side-tracked on how to do it with the currently
documented interface.

> Seems to me that they are
> a) used
> b) useful
> c) safe

We can consider making them public but in addition to the documentation
we should:

* Consider providing alternative options with more intuitive names
  and making those public instead.  Currently "-H" stands for "Home"
  which is an internal name within CMake's implementation and is not
  a name whose meaning is public-facing.

* Allow the form `-H  -B ` with the new names.

* Extend the test suite (e.g. RunCMake.CommandLine) with cases
  covering the public-facing options.

-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] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Julien Schueller]

> De: "Nils Gladitz" 
> À: "Julien Schueller" , "cmake-developers"
> 
> Envoyé: Vendredi 1 Juillet 2016 14:19:25
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 02:08 PM, Julien Schueller wrote:

>>> De: "Nils Gladitz" 
>>> À: "Julien Schueller"  , "cmake-developers"
>>> 
>>> Envoyé: Vendredi 1 Juillet 2016 13:57:40
>>> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
>>> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

>>> On 07/01/2016 01:44 PM, Julien Schueller wrote:

> De: "Nils Gladitz" 
> À: "Julien Schueller"  , "cmake-developers"
> 
> Envoyé: Vendredi 1 Juillet 2016 12:37:47
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 11:13 AM, Julien Schueller wrote:

>> I'm using find_package in no-module mode with the PATHS option to 
>> provide a
>> hard-coded guess to a path where a sublibrary 'hmat' was previously 
>> found,
>> and with the NO_DEFAULT_PATH to not find it first in system directories.
>> find_package (HMAT REQUIRED NO_MODULE PATHS /lib/cmake/hmat
>> NO_DEFAULT_PATH)

>> So far so good. Now I want to cross-compile with the usual toolchain 
>> file:
>> set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>> set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>> set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>> set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>> ...
>> This works wonderfully too.

>> But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain 
>> file to
>> prevent detecting native libraries
>> set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>> And now find_package fails to find my package!

>> I'm puzzled as I did not find in the doc something that explains why the 
>> PATHS
>> is ignored (step #8 in find_package):
>> https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package

> The given path "/lib/cmake/hmat" is prefixed by the paths in
> CMAKE_FIND_ROOT_PATH.
> Which means that (given ONLY) cmake only looks for the package in
> "/usr/i686-w64-mingw32//lib/cmake/hmat".

> You might want to e.g. add  to CMAKE_FIND_ROOT_PATH and use 
> PATHS /
> instead.

> Nils

 Thanks,

 In my case  has the same value as CMAKE_FIND_ROOT_PATH, and 
 even if
 I modify the PATHS option value to be relative (PATHS lib/cmake/hmat) the
 detection fails.
 (They're not actually set to /usr/i686-w64-mingw32 but some absolute 
 location in
 my home where I unzip a mingw toolchain, but I can reproduce the issue on
 another box where the toolchain is natively /usr/i686-w64-mingw32).

>>> I don't think behavior for relative paths is defined.

>>> Use absolute paths like "/lib/cmake/hmat", just "/" probably works as well
>>> (since the path in the prefix matches
>>> "/(lib/|lib|share)/cmake/*/").

>>> Nils

>> Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that that 
>> my
>> absolute path begins with CMAKE_FIND_ROOT_PATH and hence should be treated as
>> valid according to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ?

> CMake could do a lot of things but as-is the defined (documented) behavior is
> that when you tell cmake to only look in the prefixes provided by
> CMAKE_FIND_ROOT_PATH then all search locations are re-rooted to those 
> prefixes.

> e.g. a given path "/usr" can exist under your regular filesystem root and as
> /usr/i686-w64-mingw32/usr.
> Still you would not want cmake to look in your native /usr directory in this
> case even though it is "valid" (exists).

> Nils

I see your point. 
Thank you so much for the quick response. 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.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-developers

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

[Daniel Pfeifer]

Hi Dāvis,

On Fri, Jul 1, 2016 at 4:18 AM, Dāvis Mosāns  wrote:
> On Windows getenv uses ANSI codepage so it needs to be encoded to
> internally used encoding (eg. UTF-8). Here we use _wgetenv instead
> and encode that.

Your change to the SystemTools::GetEnv function introduces memory
leaks, since you return a pointer to a new[]-ed array.
It seems impossible to refactor SystemTools::GetEnv to use _wgetenv
and provide interface compatability.
You should probably introduce a function that returns std::string and
uses GetEnvironmentVariableW internally.

> Also typically Windows applications (eg. MSVC compiler) use current
> console's codepage for output to pipes so we need to encode that
> to internally used encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).
>
> Next, when we're outputing to console need to use wide functions.
>
> This change allows that compilers such as MSVC on Windows can be
> installed in non-ASCII path and will work correctly for all
> console's codepages which supports that path's characters.

Sounds useful. I cannot really comment on this.

Cheers, Daniel
-- 

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] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Nils Gladitz]

On 07/01/2016 02:08 PM, Julien Schueller wrote:





*De: *"Nils Gladitz" 
*À: *"Julien Schueller" ,
"cmake-developers" 
*Envoyé: *Vendredi 1 Juillet 2016 13:57:40
*Objet: *Re: [cmake-developers] PATHS guess in find_package
ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE



On 07/01/2016 01:44 PM, Julien Schueller wrote:





*De: *"Nils Gladitz" 
*À: *"Julien Schueller" ,
"cmake-developers" 
*Envoyé: *Vendredi 1 Juillet 2016 12:37:47
*Objet: *Re: [cmake-developers] PATHS guess in
find_package ignored with NO_DEFAULT_PATH &
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

On 07/01/2016 11:13 AM, Julien Schueller wrote:


I'm using find_package in no-module mode with the
PATHS option to provide a hard-coded guess to a path
where a sublibrary 'hmat' was previously found,
and with the NO_DEFAULT_PATH to not find it first in
system directories.
find_package (HMAT REQUIRED NO_MODULE PATHS
/lib/cmake/hmat NO_DEFAULT_PATH)

So far so good. Now I want to cross-compile with the
usual toolchain file:
set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
...
This works wonderfully too.

But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to
ONLY in my toolchain file to prevent detecting native
libraries
set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
And now find_package fails to find my package!

I'm puzzled as I did not find in the doc something
that explains why the PATHS is ignored (step #8 in
find_package):

https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package


The given path "/lib/cmake/hmat" is prefixed
by the paths in CMAKE_FIND_ROOT_PATH.
Which means that (given ONLY) cmake only looks for the
package in
"/usr/i686-w64-mingw32//lib/cmake/hmat".

You might want to e.g. add  to
CMAKE_FIND_ROOT_PATH and use PATHS / instead.

Nils


Thanks,

In my case  has the same value as
CMAKE_FIND_ROOT_PATH, and even if I modify the PATHS option
value to be relative (PATHS lib/cmake/hmat) the detection fails.
(They're not actually set to /usr/i686-w64-mingw32 but some
absolute location in my home where I unzip a mingw toolchain,
but I can reproduce the issue on another box where the
toolchain is natively /usr/i686-w64-mingw32).


I don't think behavior for relative paths is defined.

Use absolute paths like "/lib/cmake/hmat", just "/" probably works
as well (since the path in the prefix matches
"/(lib/|lib|share)/cmake/*/").

Nils


Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that 
that my absolute path begins with CMAKE_FIND_ROOT_PATH and hence 
should be treated as valid according 
to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ?


CMake could do a lot of things but as-is the defined (documented) 
behavior is that when you tell cmake to only look in the prefixes 
provided by CMAKE_FIND_ROOT_PATH then all search locations are re-rooted 
to those prefixes.


e.g. a given path "/usr" can exist under your regular filesystem root 
and as /usr/i686-w64-mingw32/usr.
Still you would not want cmake to look in your native /usr directory in 
this case even though it is "valid" (exists).


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

Re: [cmake-developers] cmake -E capabilities

[Robert Maynard]

On Fri, Jul 1, 2016 at 4:21 AM, Tobias Hunger  wrote:
> On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote:
>> It might be worthwhile to have the version section to have an explicit
>> dirty key instead of having to parse the string key to find that
>> information out.
>
> I'll make that information available in a separate patch and add it.

Thanks!

>
>> Also wouldn't you want server-mode to be an empty dictionary, as in
>> the future that would contain information like the wire format
>> version, etc.
>
> Getting the information here would be expensive (I would need to instanciate a
> cmServer to get the information) and I do not really see too big a need to add
> that information in the first place. Long-term I will just require a cmake 
> with
> server-mode and "serverMode": "false" is enough to tell the user that she 
> needs
> to update her cmake:-)
>
> The decision of which protocol to choose to talk to the server will be made
> later, in a different part of the code.
>

That is a very reasonable.


> Best Regards,
> Tobias
>
> --
> Tobias Hunger, Senior Software Engineer | The Qt Company
> The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
> Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
> Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
> B
-- 

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] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Julien Schueller]

> De: "Nils Gladitz" 
> À: "Julien Schueller" , "cmake-developers"
> 
> Envoyé: Vendredi 1 Juillet 2016 13:57:40
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 01:44 PM, Julien Schueller wrote:

>>> De: "Nils Gladitz" 
>>> À: "Julien Schueller"  , "cmake-developers"
>>> 
>>> Envoyé: Vendredi 1 Juillet 2016 12:37:47
>>> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
>>> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

>>> On 07/01/2016 11:13 AM, Julien Schueller wrote:

 I'm using find_package in no-module mode with the PATHS option to provide a
 hard-coded guess to a path where a sublibrary 'hmat' was previously found,
 and with the NO_DEFAULT_PATH to not find it first in system directories.
 find_package (HMAT REQUIRED NO_MODULE PATHS /lib/cmake/hmat
 NO_DEFAULT_PATH)

 So far so good. Now I want to cross-compile with the usual toolchain file:
 set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
 set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
 set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
 set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
 ...
 This works wonderfully too.

 But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain 
 file to
 prevent detecting native libraries
 set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
 And now find_package fails to find my package!

 I'm puzzled as I did not find in the doc something that explains why the 
 PATHS
 is ignored (step #8 in find_package):
 https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package

>>> The given path "/lib/cmake/hmat" is prefixed by the paths in
>>> CMAKE_FIND_ROOT_PATH.
>>> Which means that (given ONLY) cmake only looks for the package in
>>> "/usr/i686-w64-mingw32//lib/cmake/hmat".

>>> You might want to e.g. add  to CMAKE_FIND_ROOT_PATH and use 
>>> PATHS /
>>> instead.

>>> Nils

>> Thanks,

>> In my case  has the same value as CMAKE_FIND_ROOT_PATH, and 
>> even if
>> I modify the PATHS option value to be relative (PATHS lib/cmake/hmat) the
>> detection fails.
>> (They're not actually set to /usr/i686-w64-mingw32 but some absolute 
>> location in
>> my home where I unzip a mingw toolchain, but I can reproduce the issue on
>> another box where the toolchain is natively /usr/i686-w64-mingw32).

> I don't think behavior for relative paths is defined.

> Use absolute paths like "/lib/cmake/hmat", just "/" probably works as well
> (since the path in the prefix matches
> "/(lib/|lib|share)/cmake/*/").

> Nils

Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that that my 
absolute path begins with CMAKE_FIND_ROOT_PATH and hence should be treated as 
valid according to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ? 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.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-developers

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

[Ruslan Baratov via cmake-developers]

Hi,

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


Ruslo
>From 0bab30e859541dde51e9e21d3a22ec80a649a30a Mon Sep 17 00:00:00 2001
From: Ruslan Baratov 
Date: Fri, 1 Jul 2016 14:55:29 +0300
Subject: [PATCH] Add pattern for extracting file name from URL

Add one more pattern like 'https://.../archive.tar.gz?a=x=y'
to try to extract name of the archive from URL
---
 Modules/ExternalProject.cmake | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 2ff18fc..96f315f 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -1880,7 +1880,12 @@ 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}")
+  # Try: https://.../archive.tar.gz?a=x=y
+  string(REGEX MATCH "^.*/([^/]*)\\?.*$" match_result "${url}")
+  set(fname "${CMAKE_MATCH_1}")
+  if(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}")
+  endif()
 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] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Julien Schueller]

> De: "Nils Gladitz" 
> À: "Julien Schueller" , "cmake-developers"
> 
> Envoyé: Vendredi 1 Juillet 2016 12:37:47
> Objet: Re: [cmake-developers] PATHS guess in find_package ignored with
> NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

> On 07/01/2016 11:13 AM, Julien Schueller wrote:

>> I'm using find_package in no-module mode with the PATHS option to provide a
>> hard-coded guess to a path where a sublibrary 'hmat' was previously found,
>> and with the NO_DEFAULT_PATH to not find it first in system directories.
>> find_package (HMAT REQUIRED NO_MODULE PATHS /lib/cmake/hmat
>> NO_DEFAULT_PATH)

>> So far so good. Now I want to cross-compile with the usual toolchain file:
>> set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
>> set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
>> set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
>> set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
>> ...
>> This works wonderfully too.

>> But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain file 
>> to
>> prevent detecting native libraries
>> set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
>> And now find_package fails to find my package!

>> I'm puzzled as I did not find in the doc something that explains why the 
>> PATHS
>> is ignored (step #8 in find_package):
>> https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package

> The given path "/lib/cmake/hmat" is prefixed by the paths in
> CMAKE_FIND_ROOT_PATH.
> Which means that (given ONLY) cmake only looks for the package in
> "/usr/i686-w64-mingw32//lib/cmake/hmat".

> You might want to e.g. add  to CMAKE_FIND_ROOT_PATH and use 
> PATHS /
> instead.

> Nils

Thanks, 

In my case  has the same value as CMAKE_FIND_ROOT_PATH, and even 
if I modify the PATHS option value to be relative (PATHS lib/cmake/hmat) the 
detection fails. 
(They're not actually set to /usr/i686-w64-mingw32 but some absolute location 
in my home where I unzip a mingw toolchain, but I can reproduce the issue on 
another box where the toolchain is natively /usr/i686-w64-mingw32). 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.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-developers

Re: [cmake-developers] cmake -E capabilities

[Tobias Hunger]

On Do, 2016-06-30 at 14:16 -0400, Robert Maynard wrote:
> It might be worthwhile to have the version section to have an explicit
> dirty key instead of having to parse the string key to find that
> information out.

I'll make that information available in a separate patch and add it.

> Also wouldn't you want server-mode to be an empty dictionary, as in
> the future that would contain information like the wire format
> version, etc.

Getting the information here would be expensive (I would need to instanciate a
cmServer to get the information) and I do not really see too big a need to add
that information in the first place. Long-term I will just require a cmake with
server-mode and "serverMode": "false" is enough to tell the user that she needs
to update her cmake:-)

The decision of which protocol to choose to talk to the server will be made
later, in a different part of the code.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
-- 

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] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Nils Gladitz]

On 07/01/2016 11:13 AM, Julien Schueller wrote:


I'm using find_package in no-module mode with the PATHS option to 
provide a hard-coded guess to a path where a sublibrary 'hmat' was 
previously found,

and with the NO_DEFAULT_PATH to not find it first in system directories.
find_package (HMAT REQUIRED NO_MODULE PATHS 
/lib/cmake/hmat NO_DEFAULT_PATH)


So far so good. Now I want to cross-compile with the usual toolchain file:
set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
...
This works wonderfully too.

But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my 
toolchain file to prevent detecting native libraries

set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
And now find_package fails to find my package!

I'm puzzled as I did not find in the doc something that explains why 
the PATHS is ignored (step #8 in find_package):

https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package



The given path "/lib/cmake/hmat" is prefixed by the paths 
in CMAKE_FIND_ROOT_PATH.
Which means that (given ONLY) cmake only looks for the package in 
"/usr/i686-w64-mingw32//lib/cmake/hmat".


You might want to e.g. add  to CMAKE_FIND_ROOT_PATH and use 
PATHS / instead.


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

[cmake-developers] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Julien Schueller]

Hello, 

I'm using find_package in no-module mode with the PATHS option to provide a 
hard-coded guess to a path where a sublibrary 'hmat' was previously found, 
and with the NO_DEFAULT_PATH to not find it first in system directories. 
find_package (HMAT REQUIRED NO_MODULE PATHS /lib/cmake/hmat 
NO_DEFAULT_PATH) 

So far so good. Now I want to cross-compile with the usual toolchain file: 
set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32) 
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) 
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) 
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY) 
... 
This works wonderfully too. 

But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my toolchain file to 
prevent detecting native libraries 
set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY) 
And now find_package fails to find my package! 

I'm puzzled as I did not find in the doc something that explains why the PATHS 
is ignored (step #8 in find_package): 
https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package
 

Do you think it's a bug ? 

Regards, 

-- 
Julien Schueller 
Phimeca Engineering 
www.phimeca.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-developers