Re: [cmake-developers] [Patch 3/5] Improved WIX support

2016-08-02 Thread Stuermer, Michael SP/HZA-ZSEP 


> -Original Message-
> From: Nils Gladitz [mailto:nilsglad...@gmail.com]
> Sent: Tuesday, August 02, 2016 10:47 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support
> 
> On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:
> 
> > Using the patchfile support I managed to implement the service installation
> issue I had, so the unnecessary features from the last patch are removed
> now.
> >
> > I tested all patches separately and hope they work now.
> >
> > looking forward for feedback,
> >
> > best regrads,
> > Michael
> 
> Patch 3 looks OK but I think I would prefer using WiX over CPack
> nomenclature in the variables you introduce.
> 
> e.g.
> 
>  CPACK_WIX_ROOT_FEATURE_TITLE and
>  CPACK_WIX_ROOT_FEATURE_DESCRIPTION
> 
> over
> 
>  CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and
>  CPACK_WIX_ROOT_COMPONENT_DESCRIPTION
> 
> given that CPack has no concept of a root component.
> 
> Would you agree?
> 

totally. 

> Nils

Best Regards

Michael Stürmer

-- 

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 3/5] Improved WIX support

2016-08-02 Thread Nils Gladitz 

On 08/02/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


-Original Message-
From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Tuesday, August 02, 2016 10:47 AM
To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support
Patch 3 looks OK but I think I would prefer using WiX over CPack
nomenclature in the variables you introduce.

e.g.

  CPACK_WIX_ROOT_FEATURE_TITLE and
  CPACK_WIX_ROOT_FEATURE_DESCRIPTION

over

  CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and
  CPACK_WIX_ROOT_COMPONENT_DESCRIPTION

given that CPack has no concept of a root component.

Would you agree?


totally.



Thanks. I added a release note, modified the commit message and merged 
to "next" for testing:

https://cmake.org/gitweb?p=cmake.git;a=commit;h=e29bfbf2

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] [PATCH] Let CMake know that clang uses the GCC toolchain.

2016-08-02 Thread Chaoren Lin via cmake-developers 
> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work.

Huh, it doesn't look like that variable is set automatically when using
clang with the gcc toolchain. Is that supposed to happen?
It should be set manually (say, in a toolchain file)?

On Tue, Aug 2, 2016 at 10:08 AM, Brad King  wrote:

> On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> > Clang on Windows uses the GCC toolchain, so we need to avoid using
> > backslashes for paths in response files.
> [snip]
> >strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0
> ||
> >strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") ==
> 0 ||
> >strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0
> ||
> > -  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") ==
> 0) {
>
> Clang on Windows also comes in a cl-like variant whose response files may
> need backslashes.  In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work.  What goes
> wrong in your use case?
>
> 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] Allow custom osx framework locations.

2016-08-02 Thread Brad King 
On 07/30/2016 10:48 AM, David Keller wrote:
> This allows non-standard locations to be searched, e.g. brew, port.

Thanks, applied:

 CMakeFindFrameworks: Allow custom framework locations
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9970cdcb

FYI, this module really only exists for legacy reasons.  The
find_* commands know how to search frameworks already, and
support some variables that can be set to add more search
locations.

-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] FindProtobuf backward compatibility issue for PROTOBUF_IMPORT_DIRS

2016-08-02 Thread Brad King 
On 07/29/2016 11:10 PM, Konstantin Sinitsyn wrote:
> After recent changes in FindProtobuf.cmake protobuf_generate_cpp
> doesn't take into account PROTOBUF_IMPORT_DIRS (in upper case) anymore.
[snip]
> Here's the patch to fix this:

Thanks, applied:

 FindProtobuf: Restore support for PROTOBUF_IMPORT_DIRS
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5790d9b6

I've queued this for merge to 'release' for 3.6.2.

-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] QtAutogen 3.6.0 directory nesting overflow patch

2016-08-02 Thread Brad King 
On 07/31/2016 03:56 PM, Sebastian Holtermann wrote:
>> I have updated the patch for CMake 3.6.0 to fix
>> https://gitlab.kitware.com/cmake/cmake/issues/16209
> Here is an updated patch.

Thanks.  However, it is too late to restore this change for the 3.6
series.  3.6.1 reverted the change.  We can re-introduce it for 3.7
so that it can go through another round of release candidates.

Please rebase on `master` and include all needed changes as if this
change were being made for the first time, including the restoration
of the tests.

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] Use full path for all source files in ninja build.

2016-08-02 Thread Brad King 
On 08/02/2016 01:08 PM, Brad King wrote:
>  Ninja: Use full path for all source files
>  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0

I had to revert that because it causes the Qt*Autogen tests to
fail.  Also it may break builds on Windows.

There are multiple problems:

* ConvertToNinjaPath does more than just relative path conversions.
  It also converts slashes on Windows.  Furthermore, it deals with
  CMAKE_NINJA_OUTPUT_PATH_PREFIX, though that won't matter for
  absolute paths.

* Calls to AddAssumedSourceDependencies and HasCustomCommandOutput
  later in cmNinjaTargetGenerator::WriteObjectBuildStatement expect
  to be given paths that come out of ConvertToNinjaPath.

* Ninja does not seem to be able to reconcile a dependency on
  an absolute path with a build statement providing that path
  by relative path.  Custom commands that generate source files
  list their outputs with ConvertToNinjaPath.

Basically everything assumes that all paths written as inputs
or outputs of Ninja build statements have gone through the
ConvertToNinjaPath method.  The special case for "RC" in the
existing code is likely buggy.

Ninja always uses the location of the build.ninja file as
the current working directory, so an IDE that sees a relative
path in an error message can interpret it relative to that.

-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] "Run ranlib on archives only if the tool is available" not in 3.6.1 release

2016-08-02 Thread Brad King 
On 07/22/2016 04:24 PM, Ryan D Retting wrote:
> I've been waiting for the following commit to get included in an official
> release.  I just checked today's 3.6.1 and it's still not there.

3.6.1 is a patch release.  Only documentation updates and fixes for regressions
from 3.5 are eligible for patch releases.  The fix you linked was made in
post-3.6 development and will be included in 3.7.  Meanwhile the nightly
binaries or a build from source can 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] [PATCH v3 6/7] Use Windows version of Directory::Load for MinGW too

2016-08-02 Thread Brad King 
On 07/20/2016 10:27 AM, Brad King wrote:
> On 07/06/2016 03:12 PM, Dāvis Mosāns wrote:
>> Otherwise it would use POSIX functions which works only for ASCII paths.
> 
> Thanks.  Applied to KWSys first with minor tweaks:
> 
>  http://review.source.kitware.com/21349

After being rewritten by another contributor there the change is now
in KWSys master.  I've updated CMake's copy to get it:

 KWSys 2016-08-01 (560bcdbb)
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6bc3073e

-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] Let CMake know that clang uses the GCC toolchain.

2016-08-02 Thread Brad King 
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> Clang on Windows uses the GCC toolchain, so we need to avoid using
> backslashes for paths in response files.
[snip]
>strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 ||
>strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == 0 ||
>strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 ||
> -  strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0) {

Clang on Windows also comes in a cl-like variant whose response files may
need backslashes.  In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
should be detected as GNU and cause the existing code to work.  What goes
wrong in your use case?

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] Use full path for all source files in ninja build.

2016-08-02 Thread Brad King 
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> From: Chaoren Lin 
> 
> Relative paths are difficult for an IDE to parse the output of
> a build error.

Thanks, applied:

 Ninja: Use full path for all source files
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0

This is more consistent with the Makefile generator behavior too.

-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 v4 4/4] For Windows encode process output to internally used encoding

2016-08-02 Thread Brad King 
On 07/21/2016 08:43 PM, Dāvis Mosāns wrote:
> With MultiByteToWideChar such partial char would be replaced with ? (U+003F)
> or � (U+FFFD).
[snip]
> Also could check if last character is ? and try again with one byte less.

This may be a good middle ground.  The excess bytes would then be buffered
for inclusion at the beginning of the next block conversion.

How are we to know the encoding being produced by the child?

> from WaitForData we're getting data and length, and I assume that data
> might not be null-terminated but kwsysEncoding_mbstowcs expects source to be
> null-terminated and doesn't accept length.

Okay, thanks.  Using MultiByteToWideChar for Windows-specific code is
fine.  If we ever need to offer a similar generalization then we can
provide a kwsysEncoding_mbsnrtowcs later.

BTW, with all your changes to KWSys it may be easier to iterate
if you contribute to KWSys directly.  Please see instructions here:

 http://public.kitware.com/Wiki/KWSys/Git/Develop

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] Use full path for all source files in ninja build.

2016-08-02 Thread Brad King 
On 08/02/2016 02:11 PM, Chaoren Lin wrote:
> Would changing ConvertToNinjaPath to output absolute paths paths work? 

No, that will make all paths absolute.  Ninja's design is pretty clear
in that it prefers canonical relative paths when possible.

Note that the conversion to a relative path by ConvertToNinjaPath is
not unconditional.  In an out-of-source build the paths to the source
files in the source tree will be absolute.

---

Compilers know the absolute path to all the files in a translation unit
since the preprocessor was able to read them.  They could be taught to
produce absolute paths in their error messages to work better for IDEs
regardless of how the build system invokes them.  I've never really
understood why they don't make error messages and debug info hold
absolute paths.  For some reason relative paths in these places are
always blamed on the build system when in fact the compiler could
easily produce them.

-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 [attempt 2]

2016-08-02 Thread Brad King 
On 07/29/2016 06:01 AM, Tobias Hunger wrote:
> I pushed an update that takes most of the feedback into account.

Thanks.  I've applied the extra generator refactoring parts first:

 Refactor extra generator registration to use factories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc44627b

 Report more information about extra generators in generator factories
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=034caa27

Once that tests cleanly I'll merge it to `master` and then we can
rebase the remaining changes on it.

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] Use full path for all source files in ninja build.

2016-08-02 Thread Ben Boeckel 
On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers wrote:
> Similarly, the :make command in vim will have no knowledge of build.gradle,
> and only tries to parse the build errors directly.

FWIW, I haven't encountered any problems with Vim's :make with CMake's
generated Ninja files in out-of-source builds for in-source or generated
files (I almost never do in-source builds).

--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] Use full path for all source files in ninja build.

2016-08-02 Thread Chaoren Lin via cmake-developers 
> Ninja always uses the location of the build.ninja file as
> the current working directory, so an IDE that sees a relative
> path in an error message can interpret it relative to that.

Our IDE has no knowledge of the build.gradle file let alone where it is
located, it just sees the build output and tries to located the mentioned
files.
Similarly, the :make command in vim will have no knowledge of build.gradle,
and only tries to parse the build errors directly.

Would changing ConvertToNinjaPath to output absolute paths paths work?

On Tue, Aug 2, 2016 at 10:38 AM, Brad King  wrote:

> On 08/02/2016 01:08 PM, Brad King wrote:
> >  Ninja: Use full path for all source files
> >  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0
>
> I had to revert that because it causes the Qt*Autogen tests to
> fail.  Also it may break builds on Windows.
>
> There are multiple problems:
>
> * ConvertToNinjaPath does more than just relative path conversions.
>   It also converts slashes on Windows.  Furthermore, it deals with
>   CMAKE_NINJA_OUTPUT_PATH_PREFIX, though that won't matter for
>   absolute paths.
>
> * Calls to AddAssumedSourceDependencies and HasCustomCommandOutput
>   later in cmNinjaTargetGenerator::WriteObjectBuildStatement expect
>   to be given paths that come out of ConvertToNinjaPath.
>
> * Ninja does not seem to be able to reconcile a dependency on
>   an absolute path with a build statement providing that path
>   by relative path.  Custom commands that generate source files
>   list their outputs with ConvertToNinjaPath.
>
> Basically everything assumes that all paths written as inputs
> or outputs of Ninja build statements have gone through the
> ConvertToNinjaPath method.  The special case for "RC" in the
> existing code is likely buggy.
>
> Ninja always uses the location of the build.ninja file as
> the current working directory, so an IDE that sees a relative
> path in an error message can interpret it relative to that.
>
> -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] [ISSUE] Bump to 3.2 and continue...

2016-08-02 Thread Konstantin Podsvirov 
29.07.2016, 23:56, "Konstantin Podsvirov" :
> Hello CMake developers,
>
> I found bug:
>
> https://gitlab.kitware.com/cmake/cmake/issues/16220
>
> I found it, but I do not want to deal with it ...

Okay, I have solution.

May be attached patch will be more useful then MR 
(https://gitlab.kitware.com/cmake/cmake/merge_requests/51).

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

Regards,
Konstantin Podsvirov
From c9d3fada704ffe40b996b0e8b33e0ba3935c7b01 Mon Sep 17 00:00:00 2001
From: Konstantin Podsvirov 
Date: Mon, 1 Aug 2016 23:16:55 +0300
Subject: [PATCH] Remove using of continue() method

It's needed for backward compatible with CMake 2.8.4.
---
 Utilities/Sphinx/CMakeLists.txt | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/Utilities/Sphinx/CMakeLists.txt b/Utilities/Sphinx/CMakeLists.txt
index 257ba62..256f1d5 100644
--- a/Utilities/Sphinx/CMakeLists.txt
+++ b/Utilities/Sphinx/CMakeLists.txt
@@ -156,18 +156,21 @@ if(SPHINX_MAN)
 if("x${m}" MATCHES "^x(.+)\\.([1-9])\\.rst$")
   set(name "${CMAKE_MATCH_1}")
   set(sec "${CMAKE_MATCH_2}")
+  set(_m_skip FALSE)
   if(NOT CMakeHelp_STANDALONE)
 if(name STREQUAL "ccmake" AND NOT BUILD_CursesDialog)
-  continue()
-endif()
-if(name STREQUAL "cmake-gui" AND NOT BUILD_QtDialog)
-  continue()
+  set(_m_skip TRUE)
+elseif(name STREQUAL "cmake-gui" AND NOT BUILD_QtDialog)
+  set(_m_skip TRUE)
 endif()
   endif()
-  CMake_OPTIONAL_COMPONENT(sphinx-man)
-  install(FILES ${CMAKE_CURRENT_BINARY_DIR}/man/${name}.${sec}
-  DESTINATION ${CMAKE_MAN_DIR}/man${sec}
-  ${COMPONENT})
+  if(NOT _m_skip)
+CMake_OPTIONAL_COMPONENT(sphinx-man)
+install(FILES ${CMAKE_CURRENT_BINARY_DIR}/man/${name}.${sec}
+DESTINATION ${CMAKE_MAN_DIR}/man${sec}
+${COMPONENT})
+  endif()
+  unset(_m_skip)
 endif()
   endforeach()
 endif()
-- 
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 v4 4/4] For Windows encode process output to internally used encoding

2016-08-02 Thread Dāvis Mosāns 
2016-08-02 20:11 GMT+03:00 Brad King :
>
> How are we to know the encoding being produced by the child?
>

There isn't any reliable way to detect it, we just have to know what particular
application uses. Also there aren't any standard or API to determine it but
generally most applications use console's code page. Of course not all, it
could be OEM, ANSI or something else.

If application uses console's code page for pipes then app.exe | echo will
output correctly in cmd and piping in other application which also uses
it will work.

Here our issue is that when CMake checks for compiler path it gets output
from MSVC and it will give this path in console's codepage which will be
incorrectly interpreted as UTF-8 so we need to decode it first.

If there will some other application which uses different encoding then it will
need separate handling for that.
-- 

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] Use full path for all source files in ninja build.

2016-08-02 Thread Chaoren Lin via cmake-developers 
The relative path is used whenever the build directory is under the source
directory (e.g., under src/build/), so it could still be out of source.

> FWIW, I haven't encountered any problems with Vim's :make with CMake's
> generated Ninja files in out-of-source builds for in-source or generated
> files (I almost never do in-source builds).

Interesting. It appears that if you do
:set makeprg=ninja\ -C\ /path/to/build | make

then ninja will output this:

> ninja: Entering directory `/path/to/build'

and vim interprets that to be the working directory.

However, if you use these:
:set makeprg=cd\ /path/to/build\ &&\ ninja | make
:set makeprg=cmake\ --build\ /path/to/build | make
then the "Entering directory" line wouldn't appear, and vim won't know what
to do.

Our IDE uses "cmake --build /path/to/build" to invoke the build, so that we
only have to deal with CMake and not the underlying build system.

Compilers know the absolute path to all the files in a translation unit
> since the preprocessor was able to read them.  They could be taught to
> produce absolute paths in their error messages to work better for IDEs
> regardless of how the build system invokes them.


I would love to see this too, but it's much easier to fix the problem in
one place (CMake, or even just Ninja), than to fix that for every compiler.

Maybe I can try to fix ninja to resolve paths before sending them to the
compiler.
Or maybe just add a flag to ConvertToNinjaPath or something.

On Tue, Aug 2, 2016 at 11:33 AM, Ben Boeckel 
wrote:

> On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers
> wrote:
> > Similarly, the :make command in vim will have no knowledge of
> build.gradle,
> > and only tries to parse the build errors directly.
>
> FWIW, I haven't encountered any problems with Vim's :make with CMake's
> generated Ninja files in out-of-source builds for in-source or generated
> files (I almost never do in-source builds).
>
> --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 3/5] Improved WIX support

2016-08-02 Thread Nils Gladitz 

On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Using the patchfile support I managed to implement the service installation 
issue I had, so the unnecessary features from the last patch are removed now.

I tested all patches separately and hope they work now.

looking forward for feedback,

best regrads,
Michael


Patch 3 looks OK but I think I would prefer using WiX over CPack 
nomenclature in the variables you introduce.


e.g.

CPACK_WIX_ROOT_FEATURE_TITLE and
CPACK_WIX_ROOT_FEATURE_DESCRIPTION

over

CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and
CPACK_WIX_ROOT_COMPONENT_DESCRIPTION

given that CPack has no concept of a root component.

Would you agree?

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 [attempt 2]

2016-08-02 Thread Stephen Kelly 
Tobias Hunger wrote:

> Hi Stephen,
> 
> thanks for taking the time to do such a thorough review!

Actually my review wasn't thorough at all. I didn't try to review it 
further. 

The NewFactory methods in your patch don't return a new'd object, but 
instead return static locals. The regular generators NewFactory methods 
don't work that way, so you're introducing a pattern which is different to 
what already exists and the commit message doesn't say why. Maybe there's a 
reason, but I don't know what it is. In the future, no one else will know 
either.

There are lots of things in there for which your intent is unclear. That's 
why splitting and writing descriptive commit messages is valuable. You might 
find 

 https://vimeo.com/172882423

to be a good introduction to this.

I have more to ask about your first commit (and why the second commit is 
split out). I stopped my review at recommending it be split to see what it 
is hiding. 

> Added const to some of them:-) Hope I caught all.

cmake::ReportCapabilities() should be const, right?

>> * and a whitespace change that should be squashed into the commit that
>> introduces it
> 
> I used Utilities/Scripts/clang-format.bash to do the formatting, so
> that should not be an issue. I just reran that on all commits. Maybe I
> forgot it in a commit or something before.

Maybe. Running the script on all commits would be the fix anyway.

>> * The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the
>> capabilities handling:
>>
>> #if defined(CMAKE_BUILD_WITH_CMAKE)
>> else if (args[1] == "capabilities") {
>>   cmake cm;
>>   std::cout << cm.ReportCapabilities();
>>   return 0;
>> }
>> #endif
> 
> Why?

Because it's a bit odd to return 0 if capabilities can't be reported. I 
missed that the contents of that method don't compile in bootstrap mode 
though without the define.

>> As it is, it is doing many different things, none of which are mentioned
>> in the commit message, and some of which it probably shouldn't be doing.
>>
>> For example renaming GetExtraGeneratorName to
>> GetExternalMakefileProjectGeneratorName is probably not needed. If you
>> really want to do it, then it should be in its own commit with its own
>> commit message which justifies the change. As it is, it adds noise to the
>> big commit and makes it harder to review. Minimal is always better with
>> commits which do refactoring like that.
> 
> I undid that change. That is one of the things that I originally
> removed and then realized last minute that it is needed somehow. So I
> added it, not realizing that I had removed similar functionality
> earlier.

This doesn't happen if you split commits. Splitting makes these things 
visible to you and you can decide whether they were intentional or not at 
that point.

>> A general good rule of thumb (which helps reviews, and makes things
>> bisectable in the future) is to do one thing per commit.
> 
> I agree that this is the ideal we all should all strive for, but you
> are not going to get that from me anytime soon. 

Calling it an 'ideal' isn't really the right mindset. It's easy, and it's 
generally done by all other cmake contributors.

> At least not in the cmake codebase.

I don't know what this part means. It seems somehow disdainful, but I might 
be missing something. Something to talk about in person perhaps.

Thanks,

Steve.


-- 

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