Re: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015)

[Brad King]

On 09/11/2015 08:38 AM, Biddiscombe, John A. wrote:
> I have been having problems with projects in VS14 and it appears
> to be caused by the generation of paths used by/in the IDE
> 
> D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h
> 
> whereas it used to always be
> 
> D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h

Please provide a minimal test project that shows this behavior.
Also please show a snippet of the .vcxproj content that has
such slashes.

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] Fix a few issues in FindHDF5 module

[Brad King]

On 09/11/2015 12:08 PM, Paul Romano wrote:
> As requested, here's a new patch with the _NAMES variables unset()-ed
> and documentation on the HDF5_PREFER_PARALLEL variable.

Thanks.  Applied and merged to 'next' for testing:

 FindHDF5: Add NAMES_PER_DIR and introduce HDF5_PREFER_PARALLEL
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fd26a19a

I modified the wording of the documentation slightly.  Please check it.

-Brad

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] [CMake 0015737]: Use of redhat-hardened-ld breaks CMake's Fortran compiler library detection for gfortran

[Mantis Bug Tracker]

The following issue has been SUBMITTED. 
== 
http://www.cmake.org/Bug/view.php?id=15737 
== 
Reported By:Orion Poplawski
Assigned To:
== 
Project:CMake
Issue ID:   15737
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2015-09-11 13:16 EDT
Last Modified:  2015-09-11 13:16 EDT
== 
Summary:Use of redhat-hardened-ld breaks CMake's Fortran
compiler library detection for gfortran
Description: 
Fedora is now compiling everything with hardened build options. However this is
breaking CMake's fortran compiler information detection because it incorrectly
picks the wrong link line:

Detecting Fortran compiler ABI info compiled with the following output:
Change Dir:
/home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/gmake" "cmTC_41086/fast"
/usr/bin/gmake -f CMakeFiles/cmTC_41086.dir/build.make
CMakeFiles/cmTC_41086.dir/build
gmake[1]: Entering directory
'/home/orion/fedora/psi4/psi4public-1881450f30d3bd2ac91dbc4fc6a4eaa5c9f03ae5/objdir-x86_64-redhat-linux-gnu/CMakeFiles/CMakeTmp'
Building Fortran object CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o
/usr/bin/gfortran   -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
--param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
-I/usr/lib64/gfortran/modules -c
/usr/share/cmake/Modules/CMakeFortranCompilerABI.F -o
CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o
Linking Fortran executable cmTC_41086
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_41086.dir/link.txt
--verbose=1
/usr/bin/gfortran-Wl,-z,relro -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
-v -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64
-mtune=generic -I/usr/lib64/gfortran/modules  
CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o  -o cmTC_41086 -rdynamic
Driving: /usr/bin/gfortran -Wl,-z,relro
-specs=/usr/lib/rpm/redhat/redhat-hardened-ld -v -O2 -g -pipe -Wall
-Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
-I/usr/lib64/gfortran/modules
CMakeFiles/cmTC_41086.dir/CMakeFortranCompilerABI.F.o -o cmTC_41086 -rdynamic -l
gfortran -l m -shared-libgcc
Using built-in specs.
Reading specs from /usr/lib/rpm/redhat/redhat-hardened-ld
Reading specs from /usr/lib/rpm/redhat/redhat-hardened-cc1
COLLECT_GCC=/usr/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array --disable-libgcj --with-isl
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 5.1.1 20150618 (Red Hat 5.1.1-4) (GCC)
Reading specs from /usr/lib/gcc/x86_64-redhat-linux/5.1.1/libgfortran.spec
rename spec lib to liborig
COLLECT_GCC_OPTIONS='-specs=/usr/lib/rpm/redhat/redhat-hardened-ld' '-v' '-O2'
'-g' '-pipe' '-Wall' '-Werror=format-security' '-fexceptions'
'-fstack-protector-strong' '--param' 'ssp-buffer-size=4' '-grecord-gcc-switches'
'-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' '-m64' '-mtune=generic' '-I'
'/usr/lib64/gfortran/modules' '-o' 'cmTC_41086' '-rdynamic' '-shared-libgcc'
'-march=x86-64' '-pie'
COMPILER_PATH=/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/5.1.1/:/usr/libexec/gcc/x86_64-redhat-linux/:/usr/lib/gcc/x86_64-redhat-linux/5.1.1/:/usr/lib/gcc/x86_64-redhat-linux/

Re: [cmake-developers] CTest threshold exceeds 1024 bytes

[Roman Wüger]

Hello Brad,

I added the required command line options, but it doesn't produce the expected 
output.
It works in a normal environment, but not in the "CTest test case". Could you 
have a look at it?

Best Regards
Roman

> -Ursprüngliche Nachricht-
> Von: Brad King [mailto:brad.k...@kitware.com]
> Gesendet: Donnerstag, 10. September 2015 17:14
> An: Roman Wüger 
> Cc: cmake-developers@cmake.org
> Betreff: Re: [cmake-developers] CTest threshold exceeds 1024 bytes
> 
> On 09/10/2015 11:11 AM, Roman Wüger wrote:
> > I've tested it on a real world example.
> >
> > My problem is to add a "ctest unit test case".
> 
> The patch I last sent earlier in this thread adds a unit test that produces 
> and
> reads the Test.xml file.  I left a comment:
> 
>  # TODO: actually check the content
> 
> as a placeholder for you to take over with the actual check.
> At that point the "test_xml" variable holds the content to be checked.
> 
> -Brad



0001-CTest-learned-to-limit-the-output-of-passed-and-fail.patch
Description: Binary data
-- 

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 user-provided manifest files (was: Windows: Correctly determine Windows version)

[Brad King]

On 09/11/2015 11:45 AM, James Johnston wrote:
> The second request is currently a big pain point with CMake to get working
> correctly.  Ideally I want to reproduce the VS way of doing things, which
> is:
> 
> a.  Have link.exe generate default manifest for referencing the CRT
> side-by-side assemblies.
> b.  Use mt.exe to put it all together in the output.
> 
> See Source/cmcmd.cxx and search for vs_link_exe to see what I'm talking about.
[snip]
> It would be certainly be nice if CMake supported user-provided manifests
> across most/all Windows generators as first-class support, not just Visual
> Studio 10.  Especially the make-like tools (various Makefile generators,
> Ninja).  :)

I would be very happy to get rid of the vs_link_exe and vs_link_dll code.
The source is full of comments about why it is there (incremental linking).
If someone can get an alternative approach working that also supports
user-provided .manifest files I would be happy to review it.

Actually I think this should be done before the Windows 10 support can
be integrated.  We need to make sure that when a .manifest file is added
to the list of sources for an exe or dll target that we can properly
honor it in all generators.  Otherwise adding support for non-VS generators
later will be a behavior change.  Also we need to make sure the semantics
of specifying manifest sources works everywhere.

-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] CTest threshold exceeds 1024 bytes

[Brad King]

On 09/11/2015 12:37 PM, Roman Wüger wrote:
> It works in a normal environment, but not in the "CTest test case".
> Could you have a look at it?

No, sorry.  You're implementing this feature so it is up to you to
debug and get it working.

-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] Python extension to FindProtobuf

[Brad King]

On 09/11/2015 11:11 AM, Andreas Bergmeier wrote:
> Here is the commit.

Thanks.  Please revise the patch to also update the documentation
of the module to mention the new API.

> +list(APPEND ${SRCS} "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py")
> +add_custom_command(
> +  OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${FIL_WE}.pb.py"
> +  COMMAND  ${PROTOBUF_PROTOC_EXECUTABLE}
> +  ARGS --python_out  ${CMAKE_CURRENT_BINARY_DIR} 
> ${_protobuf_include_path} ${ABS_FIL}

The ARGS option can be dropped.  It is silently ignored anyway.
The arguments after it will be collected by COMMAND already.

> +  DEPENDS ${ABS_FIL} ${PROTOBUF_PROTOC_EXECUTABLE}
> +  COMMENT "Running Python protocol buffer compiler on ${FIL}"
> +  VERBATIM )
> +  endforeach()
> +
> +  set_source_files_properties(${${SRCS}} PROPERTIES GENERATED TRUE)

We do not need to explicitly set the GENERATED property.  That
convention has been outdated for years.  The add_custom_command
call automatically sets this on the OUTPUT.

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 user-provided manifest files

[Brad King]

On 09/11/2015 02:09 PM, Brad King wrote:
> I would be very happy to get rid of the vs_link_exe and vs_link_dll code.
> The source is full of comments about why it is there (incremental linking).
> If someone can get an alternative approach working that also supports
> user-provided .manifest files I would be happy to review it.

There is documentation here about what those are doing:

 https://msdn.microsoft.com/en-us/library/ms235591.aspx
 http://blogs.msdn.com/b/zakramer/archive/2006/05/22/603558.aspx

IIRC vs_link_{exe,dll} is needed to implement these steps due to all the
conditions that decide which parts are needed.  MSBuild must have something
similar in its own build rules to achieve incremental linking with embedded
manifests.  Perhaps vs_link_{exe,dll} can be updated to handle user-provided
manifest files.

> Actually I think this should be done before the Windows 10 support can
> be integrated.  We need to make sure that when a .manifest file is added
> to the list of sources for an exe or dll target that we can properly
> honor it in all generators.  Otherwise adding support for non-VS generators
> later will be a behavior change.  Also we need to make sure the semantics
> of specifying manifest sources works everywhere.

This needs to be resolved for proper Windows 10 support to be integrated
since that needs user-provided manifest files to work.

-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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Domen Vrankar]

> I have made the following changes in order to:
> - support the UID/GID/UNAME/GNAME and permission on tar files at creation
> time
> - using directly libarchive in CPackDeb
> - removing completely the need of fakeroot

Applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45

I've fixed permission mask code in patch 2 and 3. Please confirm that
it works OK in your environment.

I've also removed permission mask setting for directories and files as
I am not certain that it belongs there - it wasn't there before and
user can always change permissions with install command. Issue with
default permissions being 775 is system default related and occurs
only with directories that are automatically created - directories
created with install command get permission 755 which is acceptable
for deb packages.
I believe that this inconsistency should be fixed elsewhere by adding
possibility to set global default directory permissions.

> Is it on time for 3.4 freeze?

Feature freeze was announced for Oct, 1 so it should make it in 3.4

Regards,
Domen
-- 

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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Raffi Enficiaud]

Le 11/09/15 21:34, Domen Vrankar a écrit :

I have made the following changes in order to:
- support the UID/GID/UNAME/GNAME and permission on tar files at creation
time
- using directly libarchive in CPackDeb
- removing completely the need of fakeroot


Applied to next for testing:
http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=2e9af45


Many thanks, Domen!



I've fixed permission mask code in patch 2 and 3. Please confirm that
it works OK in your environment.


Should do, I will monitor the test this week end.



I've also removed permission mask setting for directories and files as
I am not certain that it belongs there - it wasn't there before and
user can always change permissions with install command. Issue with
default permissions being 775 is system default related and occurs
only with directories that are automatically created - directories
created with install command get permission 755 which is acceptable
for deb packages.
I believe that this inconsistency should be fixed elsewhere by adding
possibility to set global default directory permissions.



You're right, files in data.tar.xx should not have their permission 
changed from the install command, and having uid/gid root/root should 
not be any different from the behaviour we have now with fakeroot. So I 
am perfectly fine with your changes, thank you!



Is it on time for 3.4 freeze?


Feature freeze was announced for Oct, 1 so it should make it in 3.4


Good!

Cheers,
Raffi

--

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] Odd behaviour in VS14 (Visual studio 2015)

[Biddiscombe, John A.]

Brad,

I had a look at the .vcxproj files and there is no trace of odd paths in
there.
I realise now that I have #include statements of the kind
  #include 
And clearly it is VS that is appending these unixy paths to the (correct)
cmake generated path prefix for the project etc.

It appears to be a VS problem rather than a cmake one. I will investigate
elsewhere.

Thanks for the suggestion and sorry for the noise.

JB



On 11/09/15 20:15, "Brad King"  wrote:

>On 09/11/2015 08:38 AM, Biddiscombe, John A. wrote:
>> I have been having problems with projects in VS14 and it appears
>> to be caused by the generation of paths used by/in the IDE
>> 
>> D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h
>> 
>> whereas it used to always be
>> 
>> D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h
>
>Please provide a minimal test project that shows this behavior.
>Also please show a snippet of the .vcxproj content that has
>such slashes.
>
>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] Fix a few issues in FindHDF5 module

[Paul Romano]

As requested, here's a new patch with the _NAMES variables unset()-ed and
documentation on the HDF5_PREFER_PARALLEL variable.

Best,
Paul

On Wed, Sep 9, 2015 at 7:00 PM, Brad King  wrote:

> On 09/03/2015 05:16 AM, Paul Romano wrote:
> > Brad- here's a new patch based off of 8ea7611 that uses the new
> > NAMES_PER_DIR option of find_program as well adds the
> HDF5_PREFER_PARALLEL
>
> Thanks.  Please unset() the _NAMES variables when finished so that
> they are not exposed publicly.  Also please extend the module
> documentation to mention HDF5_PREFER_PARALLEL.
>
> Thanks,
> -Brad
>
>
From 1f322e8c90da7114758d63f6b75572be99d7f84b Mon Sep 17 00:00:00 2001
From: Paul Romano 
Date: Sat, 12 Sep 2015 00:07:05 +0800
Subject: [PATCH] FindHDF5: Add NAMES_PER_DIR and introduce
 HDF5_PREFER_PARALLEL

The calls to find_program now use NAMES_PER_DIR so that the first executable
(e.g. h5pcc) appearing on their PATH will get chosen. The HDF5_PREFER_PARALLEL
variable swaps the search order when it is set to true in the event that a
directory being search contains both h5cc and h5pcc.
---
 Modules/FindHDF5.cmake | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/Modules/FindHDF5.cmake b/Modules/FindHDF5.cmake
index a449132..fd990c4 100644
--- a/Modules/FindHDF5.cmake
+++ b/Modules/FindHDF5.cmake
@@ -29,7 +29,10 @@
 # To provide the module with a hint about where to find your HDF5
 # installation, you can set the environment variable HDF5_ROOT.  The
 # Find module will then look in this path when searching for HDF5
-# executables, paths, and libraries.
+# executables, paths, and libraries. In the event that both serial and
+# parallel HDF5 wrappers are found, the serial version is preferentially
+# selected. This behavior can be reversed by setting the variable
+# HDF5_PREFER_PARALLEL to true.
 #
 # In addition to finding the includes and libraries required to compile
 # an HDF5 client application, this module also makes an effort to find
@@ -103,28 +106,43 @@ else()
 endforeach()
 endif()
 
+# Determine whether to search for serial or parallel executable first
+if(HDF5_PREFER_PARALLEL)
+  set(HDF5_C_COMPILER_NAMES h5pcc h5cc)
+  set(HDF5_CXX_COMPILER_NAMES h5pc++ h5c++)
+  set(HDF5_Fortran_COMPILER_NAMES h5pfc h5fc)
+else()
+  set(HDF5_C_COMPILER_NAMES h5cc h5pcc)
+  set(HDF5_CXX_COMPILER_NAMES h5c++ h5pc++)
+  set(HDF5_Fortran_COMPILER_NAMES h5fc h5pfc)
+endif()
+
 # try to find the HDF5 wrapper compilers
 find_program( HDF5_C_COMPILER_EXECUTABLE
-NAMES h5cc h5pcc
+NAMES ${HDF5_C_COMPILER_NAMES} NAMES_PER_DIR
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 Wrapper compiler.  Used only to detect HDF5 compile flags." )
 mark_as_advanced( HDF5_C_COMPILER_EXECUTABLE )
 
 find_program( HDF5_CXX_COMPILER_EXECUTABLE
-NAMES h5c++ h5pc++
+NAMES ${HDF5_CXX_COMPILER_NAMES} NAMES_PER_DIR
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 C++ Wrapper compiler.  Used only to detect HDF5 compile flags." )
 mark_as_advanced( HDF5_CXX_COMPILER_EXECUTABLE )
 
 find_program( HDF5_Fortran_COMPILER_EXECUTABLE
-NAMES h5fc h5pfc
+NAMES ${HDF5_Fortran_COMPILER_NAMES} NAMES_PER_DIR
 HINTS ENV HDF5_ROOT
 PATH_SUFFIXES bin Bin
 DOC "HDF5 Fortran Wrapper compiler.  Used only to detect HDF5 compile flags." )
 mark_as_advanced( HDF5_Fortran_COMPILER_EXECUTABLE )
 
+unset(HDF5_C_COMPILER_NAMES)
+unset(HDF5_CXX_COMPILER_NAMES)
+unset(HDF5_Fortran_COMPILER_NAMES)
+
 find_program( HDF5_DIFF_EXECUTABLE
 NAMES h5diff
 HINTS ENV HDF5_ROOT
@@ -378,4 +396,3 @@ find_package_handle_standard_args( HDF5
 REQUIRED_VARS HDF5_LIBRARIES HDF5_INCLUDE_DIRS
 VERSION_VAR   HDF5_VERSION
 )
-
-- 
2.1.4

-- 

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] Odd behaviour in VS14 (Visual studio 2015)

[Biddiscombe, John A.]

Using cmake 3.3.1

I have been having problems with projects in VS14 and it appears to be caused 
by the generation of paths used by/in the IDE
D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h
whereas it used to always be
D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h

Note the forwardslash instead of backslash in the latest IDE

The result is that when you click on an error, the window opens up a 'new' copy 
of the file and changes you make in it are not always picked up, syntax 
highlighting, debug watches/vars don't work and I've lost quite a bit of work 
by having 'N' copies of the file open and saved one without realising another 
was open multiple times with changes in.

I will submit a bug report, but before I do, has anyone else noticed this (I'm 
afraid I don't follow the list very thoroughly and my quick check on mantis 
revealed nothing). I suspect I'm doing something wrong, so though I'd ask 
before creating an issue...

thanks

JB


--
John Biddiscombe,email:biddisco @.at.@ cscs.ch
http://www.cscs.ch/
CSCS, Swiss National Supercomputing Centre  | Tel:  +41 (91) 610.82.07
Via Trevano 131, 6900 Lugano, Switzerland   | Fax:  +41 (91) 610.82.82

-- 

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] Python extension to FindProtobuf

[Andreas Bergmeier]

Since beneath generating cpp and h files we often also want python bindings to 
be generated, I would like to have the following extension to FindProtobuf 
added.
This adds protobuf_generate_python function.

Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder 
PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die 
angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche 
Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an 
irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet 
oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich 
empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder 
durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre 
evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media 
übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, 
resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen.

This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or 
PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient 
and, therefore, may not be retransmitted to any party outside of the 
recipient's organization without the prior written consent of the sender. If 
you have received this e-mail in error please notify the sender immediately by 
telephone or reply e-mail and destroy the original message without making a 
copy. Koch Media accepts no liability for any losses or damages resulting from 
infected e-mail transmissions and viruses in e-mail attachment.
-- 

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] [CPackDeb][libarchive] removing use of fakeroot and supporting UID/GID/UNAME etc in libarchive

[Raffi Enficiaud]

Hi Brad and Domen,

This is a follow up of the following thread

http://public.kitware.com/pipermail/cmake-developers/2015-August/026125.html

I have made the following changes in order to:
- support the UID/GID/UNAME/GNAME and permission on tar files at 
creation time

- using directly libarchive in CPackDeb
- removing completely the need of fakeroot

Please review the patches (mainly 2, the other one is just a typo fix).
Or if you prefer I can just create a topic. The patches are based on 
master and are quite orthogonal.


Is it on time for 3.4 freeze?

Thanks!
Raffi
From 2f12e427c4ffe238fbf79d7c317c90b4d9c3131f Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Tue, 8 Sep 2015 23:09:01 +0200
Subject: [PATCH 1/3] Various typo fixes RunCMake.CPack: Making the error
 message somehow more readable

---
 Source/cmGeneratedFileStream.h  | 4 ++--
 Tests/RunCMake/CPack/DEB/Helpers.cmake  | 2 +-
 Tests/RunCMake/CPack/README.txt | 4 ++--
 Tests/RunCMake/CPack/VerifyResult.cmake | 7 ---
 4 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/Source/cmGeneratedFileStream.h b/Source/cmGeneratedFileStream.h
index 2aa6beb..8df3e1a 100644
--- a/Source/cmGeneratedFileStream.h
+++ b/Source/cmGeneratedFileStream.h
@@ -56,10 +56,10 @@ protected:
   // Whether the real file stream was valid when it was closed.
   bool Okay;
 
-  // Whether the destionation file is compressed
+  // Whether the destination file is compressed
   bool Compress;
 
-  // Whether the destionation file is compressed
+  // Whether the destination file is compressed
   bool CompressExtraExtension;
 };
 
diff --git a/Tests/RunCMake/CPack/DEB/Helpers.cmake 
b/Tests/RunCMake/CPack/DEB/Helpers.cmake
index a204a3c..b6f113b 100644
--- a/Tests/RunCMake/CPack/DEB/Helpers.cmake
+++ b/Tests/RunCMake/CPack/DEB/Helpers.cmake
@@ -14,7 +14,7 @@ function(verifyDebControl FILE PREFIX VERIFY_FILES)
   ERROR_VARIABLE err_)
 
   if(err_)
-message(FATAL_ERROR "Debian controll verification failed for file: "
+message(FATAL_ERROR "Debian control verification failed for file: "
 "'${FILE}'; error output: '${err_}'")
   endif()
 
diff --git a/Tests/RunCMake/CPack/README.txt b/Tests/RunCMake/CPack/README.txt
index 365c737..ea68304 100644
--- a/Tests/RunCMake/CPack/README.txt
+++ b/Tests/RunCMake/CPack/README.txt
@@ -32,14 +32,14 @@ different types of packages. This script is placed into 
CPack test root
 directory even if it will be used for only one of the generators.
 
 If test will be used for multiple generators but some of them require some
-generator speciffic commands then those commands should be added to a separate
+generator specific commands then those commands should be added to a separate
 file that should be located in '/-specifics.cmake'
 in CPack test root directory.
 
 CPack execution phase:
 --
 
-Only exececutes CPack for content that was generated during CMake execution
+Only executes CPack for content that was generated during CMake execution
 phase.
 
 Verification of generated files:
diff --git a/Tests/RunCMake/CPack/VerifyResult.cmake 
b/Tests/RunCMake/CPack/VerifyResult.cmake
index 96efa9e..6eab531 100644
--- a/Tests/RunCMake/CPack/VerifyResult.cmake
+++ b/Tests/RunCMake/CPack/VerifyResult.cmake
@@ -28,8 +28,9 @@ if(NOT EXPECTED_FILES_COUNT EQUAL 0)
 
   if(NOT expected_content_list)
 message(FATAL_ERROR
-  "Unexpected file content for file No. '${file_no_}'!"
-  " Content: '${PACKAGE_CONTENT}'"
+  "Unexpected file content for file No. '${file_no_}'!\n"
+  " Content: '${PACKAGE_CONTENT}'\n\n"
+  " Expected: '${EXPECTED_FILE_CONTENT_${file_no_}}'"
   "${output_error_message}")
   endif()
 else()
@@ -56,7 +57,7 @@ if(NOT EXPECTED_FILES_COUNT EQUAL 0)
 "${output_error_message}")
   endif()
 
-  # sanity check that we didn't accidentaly list wrong files with our regular
+  # sanity check that we didn't accidentally list wrong files with our regular
   # expressions
   foreach(expected_ IN LISTS allFoundFiles_)
 list(FIND foundFiles_ "${expected_}" found_)
-- 
2.0.1

From ba086d51479b7d5d11652d3647e5f4775d0a4f7d Mon Sep 17 00:00:00 2001
From: Raffi Enficiaud 
Date: Fri, 11 Sep 2015 16:00:28 +0200
Subject: [PATCH 2/3] cmArchiveWrite: user/group and permissions

- support for UID/GID and UNAME/GNAME
- support for permission and permission mask
- support for non-recursive folder adding
---
 Source/cmArchiveWrite.cxx | 45 ---
 Source/cmArchiveWrite.h   | 77 +--
 2 files changed, 115 insertions(+), 7 deletions(-)

diff --git a/Source/cmArchiveWrite.cxx b/Source/cmArchiveWrite.cxx
index 9f56324..a8fc85d 100644
--- a/Source/cmArchiveWrite.cxx
+++ b/Source/cmArchiveWrite.cxx
@@ -84,7 +84,11 @@ cmArchiveWrite::cmArchiveWrite(
 Archive(archive_write_new()),
 

Re: [cmake-developers] Python extension to FindProtobuf

[Rolf Eike Beer]

Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier:
> Since beneath generating cpp and h files we often also want python bindings
> to be generated, I would like to have the following extension to
> FindProtobuf added.
 This adds protobuf_generate_python function.

Forgot to add patch?

> 
> Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder
[…] Argh!

Eike
-- 

signature.asc
Description: This is a digitally signed message part.
-- 

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] Python extension to FindProtobuf

[Andreas Bergmeier]

Blindly trusting Outlook D was a bad idea ;)
Here is the commit.

(Sorry the footer is company policy)

-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf Of 
Rolf Eike Beer
Sent: Freitag, 11. September 2015 17:07
To: cmake-developers@cmake.org
Subject: Re: [cmake-developers] Python extension to FindProtobuf

Am Freitag, 11. September 2015, 14:44:21 schrieb Andreas Bergmeier:
> Since beneath generating cpp and h files we often also want python
> bindings to be generated, I would like to have the following extension
> to FindProtobuf added.
 This adds protobuf_generate_python function.

Forgot to add patch?

> 
> Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN
> und/oder
[…] Argh!

Eike
--

 Diese E-mail enthält VERTRAULICHE UND PERSÖNLICHE INFORMATIONEN und/oder 
PRIVILEGIERTE UND VERTRAULICHE MITTEILUNGEN, die ausschließlich für die 
angesprochenen Empfänger bestimmt sind. Ohne ausdrückliche schriftliche 
Zustimmung des Absenders dürfen diese Informationen und Mitteilungen nicht an 
irgendeinen Dritten außerhalb der Organisation des Empfängers weitergeleitet 
oder zur Kenntnis gebracht werden. Wenn Sie diese E-mail versehentlich 
empfangen haben, teilen Sie dies bitte dem Absender umgehend telefonisch oder 
durch Rücksendung dieser E-mail mit, und zerstören Sie die Mail sowie Ihre 
evtl. Rückmail bitte anschließend, ohne eine Kopie zu erstellen. Koch Media 
übernimmt keinerlei Verantwortung für mögliche Verluste oder Beschädigungen, 
resultierend aus virus-infizierten E-mails bzw. Viren in Anhängen.

This e-mail may contain CONFIDENTIAL AND PROPRIETARY INFORMATION and/or 
PRIVILEGED AND CONFIDENTIAL COMMUNICATION intended solely for the recipient 
and, therefore, may not be retransmitted to any party outside of the 
recipient's organization without the prior written consent of the sender. If 
you have received this e-mail in error please notify the sender immediately by 
telephone or reply e-mail and destroy the original message without making a 
copy. Koch Media accepts no liability for any losses or damages resulting from 
infected e-mail transmissions and viruses in e-mail attachment.


commit-2c9f168
Description: commit-2c9f168
-- 

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] [CMake 0015674]: Windows: Correctly determine Windows version

[Brad King]

On 09/10/2015 07:24 PM, Gilles Khouzam wrote:
> This patch fixes the issue where on Windows 8 and above, by
> default the system version returned is always Windows 8.
> 
> In order for GetVersionEx to work properly, a manifest must be
> embedded in the exe telling it to ignore the new behavior and
> give the proper version.

Thanks.  I've started by extracting the changes to GetVersionEx
calls.  Yesterday I reverted the recent RtlGetVersion change:

 Revert "Windows: Fix CMAKE_HOST_SYSTEM_VERSION on Windows >= 8.1"
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c7744c8

I rebased your patch on that and applied the part that gets the
third version component:

 Windows: Set CMAKE_HOST_SYSTEM_VERSION with three components
 http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4734df5f

I also extracted the KWSys part of the change and applied it upstream:

 http://review.source.kitware.com/20180
 http://review.source.kitware.com/20181

Once those test cleanly they will be integrated into KWSys and then
updated in CMake.  Then I can rebase everything else on top of that.

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] [CMake 0015674]: Windows: Correctly determine Windows version

[James Johnston]

Well this is quite cool. :)  It's been an issue I've wanted to see addressed
as well but haven't had the time to look at it.  Not because of CMake itself
not having a manifest (the improper GetVersionEx detection didn't affect
me), but because I need to embed an app manifest in my own programs.

I have some ideas while you are on the subject:

1.  No documentation files were updated.  I wonder if there is a good place
in the docs for this?
2.  If the user doesn't use the Visual Studio generator, still support
embedding the manifest.  For example, if I use Ninja generator in
conjunction with Visual C++'s link.exe I'd like user-specified manifests to
be merged with mt.exe.

The second request is currently a big pain point with CMake to get working
correctly.  Ideally I want to reproduce the VS way of doing things, which
is:

a.  Have link.exe generate default manifest for referencing the CRT
side-by-side assemblies.
b.  Use mt.exe to put it all together in the output.

Because CMake already does *some* things with the linker it makes it
impossible for me to cleanly specify and use link.exe manifest-related
switches myself.  For example, it hard-codes usage of link.exe /MANIFESTFILE
and the user can't specify their own location.  And the locations it does
use are undocumented.  See Source/cmcmd.cxx and search for vs_link_exe to
see what I'm talking about.  (For that matter, git grep CMake for
vs_link_exe and vs_link_dll to see how those commands end up getting used in
the first place).

Ultimately for now I wound up with this kludge to get link.exe intermediate
manifest AND my own:

if(CMAKE_CONFIGURATION_TYPES) # multiple-configuration
generator?
# WARNING:  This magic directory location is an undocumented
aspect of the
# Visual Studio generator.
list(APPEND inputManifests
 
${CMAKE_CURRENT_BINARY_DIR}/${AAM_TARGET}.dir/$/$.intermediate.manifest
)
else()
# Can't change /MANIFESTFILE because CMake assumes the
default... (see above)
list(APPEND inputManifests
$.manifest)
endif()
list(APPEND inputManifests my_own_manifests.manifest)

Which is then fed into add_custom_command( POST_BUILD COMMAND mt.exe
-manifest ${inputManifests} ).  Basically I'm hard-coding the
hard-coded /MANIFESTFILE: locations used by various CMake generators, since
it doesn't work for me to try to change it.  Obviously the situation is not
ideal because CMake makes no promises about where it puts the intermediate
manifests from the linker.

It would be certainly be nice if CMake supported user-provided manifests
across most/all Windows generators as first-class support, not just Visual
Studio 10.  Especially the make-like tools (various Makefile generators,
Ninja).  :)

Best regards,

James Johnston

From: cmake-developers [mailto:cmake-developers-boun...@cmake.org] On Behalf
Of Gilles Khouzam
Sent: Thursday, September 10, 2015 23:25
To: Brad King
Cc: cmake-developers@cmake.org
Subject: [cmake-developers] [PATCH] [CMake 0015674]: Windows: Correctly
determine Windows version

This patch fixes the issue where on Windows 8 and above, by default the
system version returned is always Windows 8.

More info on this can be found on
http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibil
ity-on-windows-7.aspx

In order for GetVersionEx to work properly, a manifest must be embedded in
the exe telling it to ignore the new behavior and give the proper version.

This patch adds support to specify manifests and teaches CMake how to embed
them using Visual Studio.
This patch adds a simple version manifest Source\cmake.version.manifest to
the CMake executables.
This removes the use of RtlGetVersion and properly uses GetVersionEx which
will now return the proper operating system version for all operating
systems until Windows 10.
This patch also fixes a potential buffer overrun and improper call of
GetVersionEx in SystemTools.cxx where GetVersionExW is called with a
OSVERSIONINFOEXA struct causing a failure since the size is improper for the
API. Fixing this, GetVersionEx should never fail anymore.
Update the OSVersionAndName for new versions of Windows released after
Windows 7.

This change will require a double compile of CMake (I'm not sure if this is
what the dashboards are doing) to have the functionality enabled, since the
first step will build a new CMake that will know how to embed a manifest.
The second compile with the version of CMake that knows how to embed a
manifest, will then embed the manifest in CMake enabling this feature.

Thanks

~Gilles

-- 

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 

Re: [cmake-developers] [CMake] Visual Studio - Ninja Generator

[James Johnston]

> -Original Message-
> From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
> On Behalf Of Brad King
> Sent: Wednesday, September 09, 2015 15:00
> To: cmake-developers@cmake.org
> Subject: Re: [cmake-developers] [CMake] Visual Studio   -
> Ninja Generator
> 
> On 09/02/2015 03:34 PM, James Johnston wrote:
> > useful if the Visual Studio generators in CMake were refactored
> > somewhat
> 
> Even without the C# motivation I think factoring out a "MSBuild" generator
> infrastructure internally will be useful.  Currently we call it "VS 10"
> because it happened to be the first version to use MSBuild project files.
> Are you proposing to have some kind of internal object model for the
> MSBuild project files to separate their construction from the actual
> generation?

Right, something like that.

Another motivation: if somebody ever wanted to write a generator for
Embarcadero C++ Builder projects... guess what format the project files are
in... MSBuild...  this otherwise has nothing to do with VStudio...

Again, not something I'm working on right now but just putting some ideas
out there. :)

> 
> > it would be useful to have Visual Studio available as an "Extra" CMake
> > generator.  For example, specification of "Visual Studio 2015 - Ninja"
> 
> This functionality sounds reasonable but the name of the extra/generator
> pair looks funny when spelled out that way.  We should consider having
> another way to specify the extra generator.

This name is consistent with the other extra generators:
http://www.cmake.org/cmake/help/v3.3/manual/cmake-generators.7.html#id12

"[Extra] generator names have the form  -
."

But I agree it is just confusing at this point.  Maybe this format could be
deprecated in favor of a new cmake.exe switch to specify an extra generator.

Best regards,

James Johnston

-- 

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