Re: [CMake] Setting permissions with CPack/WiX installer

[Nils Gladitz]

On Mon, Apr 8, 2019 at 2:07 AM Cook, Steven (G) 
wrote:

> Hi Nils,
>
>
>
> > Been a while since I looked at this but it still seems to work for me
> in 3.14.0.
>
> > Corresponding  elements are generated in files.wxs:
>
>
>
> Can you please tell me the commands you used to run cpack? I did the
> following, which didn’t give the Permission elements.
>

Remove this line
https://github.com/ngladitz/cmake-wix-testsuite/blob/master/CMakeLists.txt#L15
(I think it is superfluous/wrong and errors out when using newer cmake
versions).
>From a command line environment where your compiler is properly set up and
ninja is in PATH configure the root of the project with the Ninja generator
(currently hardcoded in the tests); use an out of source build directory
and set the REFERENCE_CMAKE_BIN_DIR cache variable to the bin-Directory of
the CMake installation you want to test.
Run e.g. "ctest -R properties" from the build directory.

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Setting permissions with CPack/WiX installer

[Nils Gladitz]

On Fri, Apr 5, 2019 at 5:25 AM Cook, Steven (G) 
wrote:

> Hi all,
>
>
>
> I would like to set the permissions on some files and directories in my
> WiX installer. It looks like the CPACK_WIX_ACL property should be suitable,
> but I can’t get it to work. There are examples of its usage in this project:
>
> https://github.com/ngladitz/cmake-wix-testsuite/tree/master/properties
>
>
>
> Typically something like this:
>
>   set_property(INSTALL
>
> empty_directory_with_property
>
> non_empty_directory_with_property
>
> PROPERTY CPACK_WIX_ACL “Everyone=GenericRead,GenericWrite,CreateFile”
>
>   )
>
>
>
> but this example doesn’t work for me with cmake 3.14.0. None of the .wxs
> files that are produced contain the expected Permission property. After
> adding some debugging to cmake, I found that
> cmCPackWIXGenerator::AddDirectoryAndFileDefinitions calls GetInstalledFile,
> which always returns NULL. This prevents the ACL from being applied.
>

Been a while since I looked at this but it still seems to work for me in
3.14.0.
Corresponding  elements are generated in files.wxs:

















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:
https://cmake.org/mailman/listinfo/cmake

[cmake-developers] Missing Bullseye coverage on CMake Dashboard

[Nils Gladitz]

Hi,

I was curious about Bullseye coverage integration with CDash and thought to
remember that this was available on CMake's Dashboard at some point.

Currently I see a "Linux-bullseye-cov" build but no entry under "Coverage".

Is that expected or did this break at some point?

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Enabling SSL support by default when building CMake from source

[Nils Gladitz]

On Thu, Aug 9, 2018 at 2:54 PM Craig Scott  wrote:

> When building CMake from source with default options, you typically end up
> without SSL support, even if the necessary libraries (i.e. OpenSSL) are
> available. I've been bitten by that in my earlier days building CMake and
> I've seen others have a similar experience. Is there any reason why this is
> the default behavior, or is it just that the logic hasn't been added to try
> to enable it by default if available?
>

I remember this having changed to some degree here (~3.6):
https://gitlab.kitware.com/cmake/cmake/commit/190a5fdffd8104ad613854bdd563a0a11dd88f63

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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] $ is not empty even if configuration has no PDB

[Nils Gladitz]

On Fri, Aug 3, 2018 at 11:31 AM Louis-Paul CORDIER 
wrote:

> How can I detect using generator expression if a file exists?
>

Since there is no first class CMake feature controlling if PDB files are
generated and since CMake does not try to interpret custom compiler flags
projects or users might be setting it doesn't necessarily know which
configurations may or may not generate PDBs.
I.e. a project might add the required compiler flags to generate PDBs in
Release configurations as well.

If you know for your use case that PDBs are generated for all
configurations except Release you could guard expansion of
$ with something like
$<$>:$> (untested) or
alternatively and perhaps cleaner and more flexible you could replace your
direct command invocation with a cmake script wrapper that checks for
existence of files before invoking the actual tool. That way it would also
work when users directly manipulated PDB specific compiler flags.

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] groups of ascii nul ('\0) characters inserted into make output but this just occurs for parallel builds

[Nils Gladitz]

On Sun, Jul 8, 2018 at 11:00 PM Alan W. Irwin 
wrote:

> My parallel builds on my Linux OS (currently Debian Buster, but this
> also happened for Debian Jessie so this is a long-standing problem)
> have ascii null ('\0) characters inserted in the output while the
> corresponding non-parallel build does not have those extra characters.
>

I narrowed it down with Ninja which buffers command outputs in parallel
builds which makes it easier to match output to specific commands.
Alternatively I think CTest launchers might have helped with this too.
CMake uses them to redirect build command outputs to distinct files for
CTest submissions.

I see null bytes coming from the "cat test.error" in the script file
generated from
https://sourceforge.net/p/plplot/plplot/ci/master/tree/plplot_test/test_c.sh.in

If this only shows up in parallel builds perhaps multiple processes are
reading/writing the same test.error file in parallel?
Haven't looked closer than that. You probably know better where to look
from there.

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:
https://cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] Race between ADD_CUSTOM_COMMAND()

[Nils Gladitz]

On 04.07.2018 18:52, Oleh Kravchenko wrote:


Hello CMake Developers!

Looks like I found interesting bug in CMake:
- ADD_CUSTOM_TARGET() always creates Makefile rule for ADD_CUSTOM_COMMAND().
- As result build simetimes failed if specified -jN for make.


FWIW this is documented behavior (so not exactly a bug):
https://cmake.org/cmake/help/latest/command/add_custom_command.html

"Do not list the output in more than one independent target that may 
build in parallel or the two instances of the rule may conflict[...]".


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:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [CMake] CMAKE_SYSROOT

[Nils Gladitz]

On Tue, Jul 3, 2018 at 3:06 PM dbegun via CMake  wrote:

> I am cross-compiling some code for ARM on an x86 host with cmake 3.5.1.
> The code has multiple dependencies, and I placed relevant cross-compiled
> libraries in /home/dev/arm_build. I was hoping that
> specifying CMAKE_SYSROOT=/home/dev/arm_build in my CMAKE_TOOLCHAIN_FILE
> would prefix it to the search path of the find_* commands, so I won't have
> to modify existing Find*.cmake files. However, when I do that, cmake is
> unable to locate the compiler's libc files (my compiler also resides in
> /home/dev/arm_build) and is unable to compile a test program, not finding
> crt1.o, crti.o etc. Without specifying CMAKE_SYSROOT things work, it's just
> that I have to edit the Find*.cmake files. I can live with that, but any
> suggestions?
>

It sounds like what you'd want is:
https://cmake.org/cmake/help/latest/variable/CMAKE_FIND_ROOT_PATH.html

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] target_include_directories and system headers

[Nils Gladitz]

On Thu, Jun 28, 2018 at 7:12 AM Jim Lloyd  wrote:

> [...]
> But if I make a trivial project that simply includes yaml-cpp as a
> dependency, the generated compile commands use `-isystem` to include the
> yaml-cpp headers.
>
> Is this a bug in CMake?
>
> Also, is there any way I may be able to work around this problem with
> CMake 3.10? I would be happy to globally force the use of `-I` for all
> include directories.
>

I think the question and a potential work around are covered by
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#include-directories-and-usage-requirements
Specifically the paragraph close to the end starting with "When the
INTERFACE_INCLUDE_DIRECTORIES of an imported target...".

Basically include directories inherited from imported targets are
implicitly "SYSTEM" by default.

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Is it possible for CMake to generate unescaped quotes on the (bash) command line as a result of add_custom_command?

[Nils Gladitz]

On 13.04.2018 21:48, Alan W. Irwin wrote:

[...]
However, that is wrong since that command currently needs two 
arguments even if

one of them is empty.  So instead I need the generated command to be

./test-drv-info "temporary_target_" ps > 
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info


or

./test-drv-info "" ps > 
/home/software/plplot/HEAD/build_dir/drivers/test_dyndrivers_dir/ps.driver_info


depending on how LIBRARY_TARGET_PREFIX is set.

Is it possible to implement that?


Hi Alan,

with VERBATIM just using regular unescaped quotes (which are cmake 
syntax and not part of the value) around the argument should work e.g.


    COMMAND test-drv-info "${LIBRARY_TARGET_PREFIX}" 
${SOURCE_ROOT_NAME} 
${CMAKE_CURRENT_BINARY_DIR}/test_dyndrivers_dir/${SOURCE_ROOT_NAME}.driver_info



That way even when ${LIBRARY_TARGET_PREFIX} expands empty 
add_custom_command() will receive an argument which it will escape / 
quote as required by the build system.


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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] What are the actual benefits of namespaced targets?

[Nils Gladitz]

On 10.03.2018 23:01, Alan W. Irwin wrote:

Anyhow, your thoughts would be appreciated for reasonable best
practice limits on how far (if any) beyond the common code case you
would go to convert an old project to use
ALIAS libraries and modules in the build tree that have to be
implemented in any case for CMake code that is common to
both the build tree and install tree. 



Hello Alan,

I agree with your assessments.

Assuming a project that is highly structured through directory scopes I 
might consider the following.


Any target is defined in exactly one directory scope.
Any command that extends the definition of a target has to use the 
original target name and should be in the same directory scope.


In all other directory scopes I'd consider consistent use of a target's 
alias.


While it is less likely for a seasoned developer to trip over the 
interpretation ambiguity in link libraries (due to familiarity and the 
fact that they probably already tripped over this and know the symptoms) 
it might still be beneficial for new / casual contributors which as 
likely consumers might also already be familiar with the aliases.


One minor additional benefit might be that you are also not allowed to 
modify the original target through an alias.
As such this would prevent you (assuming you stick to the namespaced 
names) from modifying targets from within foreign scopes which I think 
is a good thing to enforce.


Beyond that consumers might be looking at your code base for examples on 
how to use the libraries in their own code where consistency might be 
beneficial.
It might also help (slightly) if you ever decided to split off parts of 
your project into new projects (which then would become consumers of the 
exported targets).


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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] What are the actual benefits of namespaced targets?

[Nils Gladitz]

On 08.03.2018 19:50, Alan W. Irwin wrote:

So what are the actual benefits of namespacing the exported targets
associated with libraries? 


On the consumer side it makes linking to targets less error prone.

When you link to a library target without a namespace and e.g. get the 
name or scope wrong CMake will silently assume that you want to link a 
library by name (e.g. in context of gcc "foo" becomes "-lfoo").
When the library and its headers happens to be in the compiler's 
standard search directories this might not even get caught at build time 
right away.


When the library target has a namespace CMake will require the given 
name to be a target and will fail during generation if the target is not 
actually available.


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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] Do any CMake back ends have support for parallel builds that efficiently use clusters?

[Nils Gladitz]

On Fri, Jan 12, 2018 at 10:58 AM, Alan W. Irwin 
wrote:

> I am looking into the practicality of using clusters containing ~5
> cheap ARM 8-core computers (such as the Banana Pi M3) to rapidly build
> and test software (since even with ccache I am currently spending a
> lot of my time waiting for tests to complete as I develop my
> software).  Such clusters would give you ~40 cores which is a lot of
> computer power for ~$500 or so.  But, of course, the issue with
> clusters is how to use them efficiently?
>

I don't know anything about MPI but would distributed compilation via icecc
(icecream) [1] or distcc be an option?
Should work with both the Makefile and Ninja generators (replace compilers
with icecc/distcc compiler wrappers).

Nils

[1] https://github.com/icecc/icecream
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CTest not searching for the correct executable

[Nils Gladitz]

On 05.01.2018 17:11, Saad Khattak wrote:

Hi,

Suppose I have something like this:

add_executable(MyTest main.cpp)
set_target_properties(MyTest
  PROPERTIES
  DEBUG_POSTFIX _d
  RELEASE_POSTFIX _r
  )
add_test(RunTests MyTest) # where MyTest is the 

I expect CMake to recognize that "MyTest" has executables that are 
named "MyTest_d" and "MyTest_r" and NOT MyTest. I expect this because 
in the CMake documentation the  can be an executable target 
where CMake then replaces it with the location of the executable.


However, what I get is errors when running "ctest" where it complains 
that it cannot find "MyTest" when it should really be searching for 
"MyTest_d" and "MyTest_r".


Am I doing something wrong or is this a bug in CMake?


You are using the old signature (without NAME|COMMAND) for which the 
documentation states [1]:
    "Unlike the above |NAME| signature no transformation is performed 
on the command-line to support target names or generator expressions."


Use the new signature instead e.g.:
    add_test(NAME RunTests COMMAND MyTest)

Nils

[1] https://cmake.org/cmake/help/latest/command/add_test.html
-- 

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:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] CMakeLists.txt location

[Nils Gladitz]

On 13.09.2017 14:31, Alain Miniussi wrote:



On 13/09/2017 12:49, Nils Gladitz wrote:

 [...]
Do you have a minimal reproducible example for that behaviour?


e.g. given:

   cmake_minimum_required(VERSION 2.8.0)

project(Foo NONE)

file(WRITE foo/CMakeLists.txt "add_executable()")

add_subdirectory(foo)


I get:

CMake Error at foo/CMakeLists.txt:1 (add_executable):
  add_executable called with incorrect number of arguments


Even with the oldest CMake version currently available to me (2.8.0).

That test case works for me too. But my real case does not.
I think it would be tricky to minimized, what is failling is the 
second run of cmake, after a modification in the build system or in a 
configure_file source.



CMake Error at CMakeLists.txt:14 (add_executable):
  Target "cmTC_60ee6" links to item " -Xlinker --enable-new-dtags 
-Xlinker

  -rpath -Xlinker
/opt/software/common/intel/impi/2017.0.098/intel64/lib/release_mt 
-Xlinker

  -rpath -Xlinker /opt/software/common/intel/impi/2017.0.098/intel64/lib
  -Xlinker -rpath -Xlinker 
/opt/intel/mpi-rt/2017.0.0/intel64/lib/release_mt

  -Xlinker -rpath -Xlinker /opt/intel/mpi-rt/2017.0.0/intel64/lib
/opt/software/occigen/libraries/boost/1_63_0/intel/17.0/intelmpi/2017.0.098/lib/libboost_serialization.a" 

  which has leading or trailing whitespace.  This is now an error 
according

  to policy CMP0004.


CMake Error: Internal CMake error, TryCompile generation of cmake failed
INFO   Boost MPI not available or too old:


Now, maybe the problem is with a CMakeLists.tx generated by a 
try_compile.

Indicating that I would actually need the location of the try_compile.

Thanks

Alain 


Ok, I assume that means you are actually looking at CMakeError.log and 
not the output you get from CMake concerning your own project's 
configuration run.
try_compile() runs aren't necessarily meant to succeed but rather their 
outcome is used in conditionals which may or may not have fatal outcomes 
for your actual project.


If a fatal diagnostic is produced based on such a conditional it would 
be visible in CMake's direct output (with file and line information) not 
CMakeError.log.
You only need to look at CMakeError.log to understand why a 
try_compile() did not succeed even though you would have expected it to.


The CMakeLists.txt where the error comes from in your failing 
try_compile() is generated and temporary so you will not find it in your 
own sources.


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

Re: [CMake] CMakeLists.txt location

[Nils Gladitz]

On 13.09.2017 12:22, Alain Miniussi wrote:



On 13/09/2017 11:16, Nils Gladitz wrote:

On 13.09.2017 10:52, Alain Miniussi wrote:

Hi,

Is there a way, when printing CMake error, to get the exact location 
of the CMakeLists.txt ?


For example, right now, when I have:

CMake Error at CMakeLists.txt:14 (add_executable):

I  need to scan all my CMakeLists.txt (~200) to check which one has 
add_executable at line 14. 


CMake includes the (relative to the root source directory) path for 
me e.g.:

CMake Error at Source/CMakeLists.txt:4 (add_executable):

Well, it never did for me:
$grep add_executable CMakeLists.txt
$

Alain



Do you have a minimal reproducible example for that behaviour?


e.g. given:

   cmake_minimum_required(VERSION 2.8.0)

project(Foo NONE)

file(WRITE foo/CMakeLists.txt "add_executable()")

add_subdirectory(foo)


I get:

CMake Error at foo/CMakeLists.txt:1 (add_executable):
  add_executable called with incorrect number of arguments


Even with the oldest CMake version currently available to me (2.8.0).


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

Re: [CMake] CMakeLists.txt location

[Nils Gladitz]

On 13.09.2017 10:52, Alain Miniussi wrote:

Hi,

Is there a way, when printing CMake error, to get the exact location 
of the CMakeLists.txt ?


For example, right now, when I have:

CMake Error at CMakeLists.txt:14 (add_executable):

I  need to scan all my CMakeLists.txt (~200) to check which one has 
add_executable at line 14. 


CMake includes the (relative to the root source directory) path for me e.g.:
CMake Error at Source/CMakeLists.txt:4 (add_executable):

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

Re: [CMake] Regex Matching

[Nils Gladitz]

On 23.08.2017 22:21, Andrew Bell wrote:

Hi,

Can someone please explain the cmake regex matching rules?

The following returns true:

if ("This is a test" MATCHES "test")

I would have expected to have needed something like this to get a match:

if ("This is a test" MATCHES ".*test")

Does cmake always search for a subexpression?  Is there some way to 
prevent this behaivor?


The regex syntax is documented here:
https://cmake.org/cmake/help/latest/command/string.html#regex-specification

if ("This is a test" MATCHES "^test")

Would match "test" only at the beginning of the input.

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

Re: [CMake] CPackWIX and MS Visual Studio Redistributable *.MSM

[Nils Gladitz]

On Thu, Aug 17, 2017 at 3:10 PM, Matwey V. Kornilov <
matwey.korni...@gmail.com> wrote:

> Hello,
>
> What is recommended way to locate and merge MS redistributable *.msm file
> into final *.msi installer produced by CPack and WIX?
>
> It seems to be a quite common task but I cannot find any mention.
>

 I've never tried this myself.

You probably already found:

http://wixtoolset.org/documentation/manual/v3/howtos/redistributables_and_install_checks/install_vcredist.html

Perhaps the patch mechanism in the WIX generator can be used to insert the
required snippets into the generated XML:

https://cmake.org/cmake/help/latest/module/CPackWIX.html#variable:CPACK_WIX_PATCH_FILE

I don't outright know where the msm files are stored or what would be the
best way to locate them.

I suppose it might not be that common in a CMake context because it would
be CPack generator and compiler specific while the competing
https://cmake.org/cmake/help/latest/module/InstallRequiredSystemLibraries.html
is both generator and compiler agnostic.

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

Re: [CMake] The C compiler "/usr/bin/cc" is not able to compile a simple test program.

[Nils Gladitz]

On 30.07.2017 10:54, Micha Hergarden wrote:

On 30-07-17 04:36, jupiter wrote:
I thought if I add -DCMAKE_CC_COMPILER=gcc that error should go, no, 
it still compile with the specific default cc:


The corresponding CMake cache variable for the C compiler is 
CMAKE_C_COMPILER (note C not CC).


Also note if the C compiler has already been configured for a build tree 
it can not simply be changed.
Which is also why the CC environment variable has no effect on build 
trees where the C compiler is already configured.


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

Re: [CMake] setting PYTHONPATH for test

[Nils Gladitz]

On 30.07.2017 03:22, Kris Thielemans wrote:


Hi

I’m trying to add to the PYTHONPATH for a test that uses Python. I do 
that using set_test_properties. When using the makefile generator, I 
need to add ${CMAKE_CURRENT_BINARY_DIR}. However, for Visual Studio I 
also need to add for instance ${CMAKE_CURRENT_BINARY_DIR}/Release.


My current CMakeLists.txt works only on Windows and when building 
Release mode:


add_test(${name} “${PYTHON_EXECUTABLE}" ${testfile} )

   set_tests_properties ( ${name} PROPERTIES ENVIRONMENT

"PYTHONPATH=${CMAKE_CURRENT_BINARY_DIR}/Release\;${CMAKE_CURRENT_BINARY_DIR}")

I have 2 problems:

  * How do I figure out which configuration is being used?
$ doesn’t seem to work inside
set_test_properties (it just gets passed verbatim)



Try using the NAME/COMMAND signature of add_test() e.g.
add_test(NAME ${name} COMMAND “${PYTHON_EXECUTABLE}" ${testfile})

It should enable generator expression processing in test properties.

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

Re: [CMake] How to get list of generated object-files of OBJECT-library?

[Nils Gladitz]

On 17.07.2017 17:13, Deniz Bahadir wrote:

Am 17.07.2017 um 16:47 schrieb Nils Gladitz:

On 7/17/2017 3:52 PM, Deniz Bahadir wrote:


This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols 
in the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two 
add_library commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$<TARGET_OBJECTS:${PROJECT_NAME}_OBJECT>

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$<TARGET_OBJECTS:${PROJECT_NAME}_OBJECT>

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable
  for consumption by CMake.  It is not suitable for writing out 
elsewhere.

```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can 
pass it to another program that should be run as additional 
build-step before linking?


IMHO, the most comfortable (and syntactically cleanest) way would be 
my first attempt. But that is probably more a feature-request than a 
simple question.


FWIW this was implemented in the upcoming 3.9:
https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component 



Thank you for your answer, Nils, but I do not really see how this 
relates.
This command seems to address CPack, while I am still struggling with 
CMake building files (that later might be installed by CPack). 


So sorry about that.
Must have gotten the wrong link in my clipboard.

The correct link is:
https://cmake.org/cmake/help/latest/release/3.9.html#other

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

Re: [CMake] How to get list of generated object-files of OBJECT-library?

[Nils Gladitz]

On 7/17/2017 3:52 PM, Deniz Bahadir wrote:


This works just fine. However, now I want to add an additional 
build-step after creation of the object-files and before linking the 
shared library. (In particular, I want to compress the debug-symbols 
in the object-files. But that should be irrelevant for my question.)


My first attempt was to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME}_OBJECTS POST_BUILD
COMMAND objcopy --compress-debug-sections 
$

)
```
But that results in the following error:
```
(add_custom_command):
  Target "MyProject_OBJECTS" is an OBJECT library that may not
  have PRE_BUILD, PRE_LINK, or POST_BUILD commands.
```

So I tried instead to add the following between the two add_library 
commands:

```
add_custom_command( TARGET ${PROJECT_NAME} PRE_LINK
COMMAND objcopy --compress-debug-sections 
$

)
```
This then fails when evaluating the generator-expression:
```
(add_custom_command):
  Error evaluating generator expression:

$

  The evaluation of the TARGET_OBJECTS generator expression is only 
suitable
  for consumption by CMake.  It is not suitable for writing out 
elsewhere.

```

So I am currently out of ideas (which do not make the CMakeLists.txt 
file completely unmaintainable). Therefore my question is:


How can I retrieve the list of generated object-files so that I can 
pass it to another program that should be run as additional build-step 
before linking?


IMHO, the most comfortable (and syntactically cleanest) way would be 
my first attempt. But that is probably more a feature-request than a 
simple question.


FWIW this was implemented in the upcoming 3.9:
https://cmake.org/cmake/help/latest/module/CPackIFW.html#command:cpack_ifw_configure_component

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

Re: [cmake-developers] Using USES_TERMINAL in ExternalProject.cmake

[Nils Gladitz]

On 13.07.2017 22:19, Robert Dailey wrote:

I noticed that ExternalProject_Add() has this same issue when run from
Ninja. I do not see real-time output of the progress. Would it work to
set USES_TERMINAL for most (if not all) custom commands and targets in
ExternalProject.cmake?


See the USES_TERMINAL_* options in 
https://cmake.org/cmake/help/latest/module/ExternalProject.html (since 
3.4) but beware that there can be only one job in the console pool at a 
time so this might also reduce parallelization.


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] Warning: Argument not separated from preceding token by whitespace.

[Nils Gladitz]

On Mon, Jun 26, 2017 at 10:33 AM,  wrote:

> Hello,
>
> I've got the following code in a cmake file:
>
> 109 add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/tmp-pcode-
> matlab/knitromatlab_fsolve.p
> 110   ${CMAKE_BINARY_DIR}/tmp-pcode-
> matlab/knitromatlab_lsqnonlin.p
> 111   ${CMAKE_BINARY_DIR}/tmp-pcode-
> matlab/knitromatlab_mip.p
> 112COMMAND ${Matlab_MAIN_PROGRAM} -nodisplay
> -nodesktop -nosplash -r \"run('${CMAKE_BINARY_DIR}/generate_pcode.m')\;\"
> 113WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
> 114COMMENT "Generating PCode")
>
>
> When I run cmake, I've got the following warning message:
>
> CMake Warning (dev) in matlab/CMakeLists.txt:
>   Syntax Warning in cmake code at
>
> /home/jenkins/workspace/Knitro/KnitroLinux/KNITROdir/
> matlab/CMakeLists.txt:112:131
>
>
Try:

add_custom_command(OUTPUT ${CMAKE_BINARY_DIR}/tmp-pcode-
matlab/knitromatlab_fsolve.p
 ${CMAKE_BINARY_DIR}/tmp-pcode-matlab/knitromatlab_lsqnonlin.p
 ${CMAKE_BINARY_DIR}/tmp-pcode-matlab/knitromatlab_mip.p
 COMMAND ${Matlab_MAIN_PROGRAM} -nodisplay -nodesktop -nosplash -r
"run('${CMAKE_BINARY_DIR}/generate_pcode.m');"
 VERBATIM
 WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
 COMMENT "Generating PCode")

Note the removal of all escape sequences and the addition of VERBATIM.
You don't want literal quotes but rather want to leave platform/generator
specific quoting to CMake.

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

Re: [CMake] Platform dSPACE

[Nils Gladitz]

On 23.06.2017 21:47, Robin Verschueren wrote:

Dear CMake,

We are trying to build our application for the dSPACE embedded system
(www.dspace.com ), more specifically their 
MicroAutobox-II. This makes
use of a specific compiler called mccppc (Microtec C/C++ PowerPC 
compiler).


I was following the instructions on this wiki page 
, when I got the 
following warning,

when trying to use a custom 'Toolchain' file:

System is unknown to cmake, create:

Platform/dSPACE to use this system, please send your config file to

cm...@www.cmake.org  so it can be added to 
cmake



We would be glad to send it to you when it is finished, but in the 
meantime,

we cannot debug our toolchain file because of above warning.

Is there a way of including it without having to include it in the 
official CMake

distribution? I tried setting CMAKE_MODULE_PATH but that did not help..


In the Toolchain file:
set(CMAKE_SYSTEM_NAME dSPACE)

list(APPEND CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR})

...

Then having Platform/dSPACE.cmake next to your toolchain file should 
work (works for me).


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

Re: [CMake] Is there a way to produce the documentation of cmake in xml format?

[Nils Gladitz]

On 07.06.2017 21:23, Martin Weber wrote:

Hi all,

is there a way to extract the documentation from cmake-sources and convert
that to XML?
I am trying to work on CmakeEd [1]. This Eclipse plugin has support for
editing cmakelists files (syntax highlighting, code completion), but only for
cmake 2.8 which I want to update.
If I had docs in XML I could use XSLT to produce my files instead of typing
all the stuff...

Any ideas?
Martin


CMake uses the Sphinx documentation system:

http://www.sphinx-doc.org


One of the supported builders is "xml" (Docutils-native XML).


Assuming you've installed sphinx and enabled e.g. SPHINX_HTML 
(-DSPHINX_HTML=ON) you could try a verbose build of the "documentation" 
target to see how a sphinx-build invocation looks like.


To change the builder modify the argument after the -b option (e.g. 
replace "html" with "xml").



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

Re: [CMake] DLL handling under CMake

[Nils Gladitz]

On 04/27/2017 10:43 AM, Louis-Paul CORDIER wrote:

I added my current code for handling Qt library in my project at the 
end of this email. (I put a huge part of it if someone want to reuse 
it). You will notice that this code is handling the case where you are 
debugging using Visual Studio, to avoid the missing .DLL issue.


FWIW in case of Qt5 you do not have to manually construct or guess DLL 
locations.


You can retrieve the DLL locations from the imported targets (e.g. 
"Qt5::Widgets") that Qt5 provides by querying the LOCATION_ 
target properties (e.g. LOCATION_DEBUG or LOCATION_RELEASE).


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

Re: [CMake] fftw library in cmake

[Nils Gladitz]

On 04/21/2017 03:40 PM, aishwarya selvaraj wrote:


add_library(fftw STATIC IMPORTED)

[...]

TARGET_LINK_LIBRARIES(prose fftw  )

[...]
make[2]: *** No rule to make target `fftw-NOTFOUND', needed by 
`prose'. Stop.


You are creating an IMPORTED target "fftw" but you aren't populating its 
IMPORTED_LOCATION [1] (or IMPORTED_LOCATION_ [2]) target property.

Without it CMake does not know what on disk library file to link to.

You can set target properties with set_property() or 
set_target_properties().


Nils

[1] https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION.html
[2] 
https://cmake.org/cmake/help/latest/prop_tgt/IMPORTED_LOCATION_CONFIG.html
-- 

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

Re: [CMake] CMake uses semi-colon as path separator on Linux

[Nils Gladitz]

On 14.04.2017 06:05, Pawel Veselov wrote:

Hello.

I really can't understand what's going on. Trying to compile my project
for android, setting all kinds of things to get it done. I've tried 3.8.0,
3.7.2 and 3.6.2, with the same result. The below extracts are from running
3.6.2

Running with --debug and --trace, I see:

/usr/share/cmake/Modules/FindPkgConfig.cmake(91):
_pkgconfig_set(JSONC_CFLAGS ${_pkgconfig_invoke_result} )
/usr/share/cmake/Modules/FindPkgConfig.cmake(64):  set(JSONC_CFLAGS
-I/tmp/arm-23/include/json-c;-I/tmp/arm-23/include CACHE INTERNAL  )

I ran strace, and I can see pkg-config returning paths normally, just spaces.

Running make on the generated makefiles:

/tmp/arm-23/bin/arm-linux-androideabi-gcc-g -ggdb -O0 --std=c99
-isystem/home/vps/ws/EF/DMClient/android_src/http-parser
-isystem/usr/include
-isystem/home/vps/ws/EF/DMClient/android_src/wslay/lib/includes
-I/tmp/arm-23/include/json-c;-I/tmp/arm-23/include -isystem
/tmp/arm-23/include -isystem /tmp/arm-23/include/libxml2   -o
CMakeFiles/dmclient.dir/config.c.o   -c
/home/vps/ws/EF/DMClient/config.c

The semicolons are in the ./CMakeFiles/node_editor.dir/flags.make

The CMakeLists.txt has this line:
pkg_check_modules(JSONC REQUIRED json-c openssl)

At this point, I'm running CMake without any fancy command, the compiler
location and such are derived from environment variables.

I tried using the NDK flags (with 3.8, and using toolchain), but then
realized this reproduces even without them (and on 3.6)

Any idea what drags in those semicolons?


CMake uses semicolons to separate list elements:
https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#lists

Some CMake commands / variables / properties expect ";"-separated lists 
(e.g. target_compile_options(), COMPILE_OPTIONS) and some expect strings 
with whitespace separated arguments (e.g. CMAKE_C_FLAGS, COMPILE_FLAGS).


Presumably you are feeding the list to something that expects the latter.

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

Re: [CMake] Directing cmake to link against shared object with debug postfix (_d)

[Nils Gladitz]

On 12.04.2017 17:48, Olumide wrote:

Thanks Nils.

BTW, shouldn't that be
ContinuumTransfunctioner$<$:_d>
Transmogrifier$<$:_d>


Ah right given your specific case, yes.

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

Re: [CMake] Directing cmake to link against shared object with debug postfix (_d)

[Nils Gladitz]

On 04/12/2017 04:49 PM, Olumide wrote:


set(Libraries
ContinuumTransfunctioner${CMAKE_DEBUG_POSTFIX}
Transmogrifier${CMAKE_DEBUG_POSTFIX}
)


Perhaps try with generator expressions:

set(Libraries
ContinuumTransfunctioner$<$:d>
Transmogrifier$<$:d>
)

Maybe alternatively create a find module and populate imported targets 
with the required information:

https://cmake.org/cmake/help/latest/manual/cmake-developer.7.html#find-modules

Or assuming ContinuumTransfunctioner and Transmogrifier are created by 
an independent CMake project under your control look into target exports 
and package configuration files:

https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html#creating-packages

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

Re: [CMake] Linker error when building 3.8.0-rc4 on Linux

[Nils Gladitz]

On 31.03.2017 22:44, Alan W. Irwin wrote:


Therefore, from the sidelines I am encouraging you guys to be
extraordinarily careful about this particular issue; e.g., by
attempting to to confirm this CMake-3.8.0-rc4 issue independently for
Ubuntu 16.10.



FWIW I tried reproducing it from within an Ubuntu 16.10 Docker container 
and it worked there as-is.



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

Re: [CMake] Linker error when building 3.8.0-rc4 on Linux

[Nils Gladitz]

On 03/31/2017 11:54 AM, Alan W. Irwin wrote:


Hi Nils:

And use of ExternalProject_Add, etc.  In other words, this is a pretty
crippling restriction for users with Linux distributions (such as the
quite recent Ubuntu 2016.10 of the original poster) that do not yet
give access to libssl version 1.1.0 (the oldest version of libssl
where HMAC_CTX_new() and HMAC_CTX_free() are available according to
your previous post).


Strangely enough I have no issue on Ubuntu 16.04 with the system default 
installation of OpenSSL.


What I missed in the original post is that the error comes from 
libarchive rather than libcurl.
But libarchive itself also seems to provide inline definitions of the 
missing functions in 
Utilities/cmlibarchive/libarchive/archive_openssl_hmac_private.h for 
OpenSSL < 1.1.


I can't tell why the inline definitions aren't used on the original 
posters system.

Perhaps there is a mismatch between OpenSSL headers and libraries?


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

Re: [CMake] Linker error when building 3.8.0-rc4 on Linux

[Nils Gladitz]

On 03/31/2017 09:04 AM, ウルヰ wrote:


To disable OpenSSL e.g. "cmake ... -DCMAKE_USE_OPENSSL=false" or "bootstrap
... --  -DCMAKE_USE_OPENSSL=false".

What would be the ramifications of building CMake without OpenSSL?


As far as I am aware it would mean no "https://; support in curl which 
would mean no "https://; support in e.g. file(DOWNLOAD) and CTest 
submissions.


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

Re: [CMake] Linker error when building 3.8.0-rc4 on Linux

[Nils Gladitz]

On 03/31/2017 07:46 AM, ウルヰ wrote:


../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_hmac.c.o):
In function `__hmac_sha1_init':
archive_hmac.c:(.text+0x25): undefined reference to `HMAC_CTX_new'
../Utilities/cmlibarchive/libarchive/libcmlibarchive.a(archive_hmac.c.o):
In function `__hmac_sha1_cleanup':
archive_hmac.c:(.text+0x12d): undefined reference to `HMAC_CTX_free'
collect2: error: ld returned 1 exit status
Source/CMakeFiles/ccmake.dir/build.make:422: recipe for target
'bin/ccmake' failed
make[2]: *** [bin/ccmake] Error 1
CMakeFiles/Makefile2:2314: recipe for target
'Source/CMakeFiles/ccmake.dir/all' failed
make[1]: *** [Source/CMakeFiles/ccmake.dir/all] Error 2
Makefile:162: recipe for target 'all' failed
make: *** [all] Error 2

Is this a bug with the build configuration or have I forgotten to do
something I need to do?


According to the OpenSSL documentation HMAC_CTX_new() and 
HMAC_CTX_free() were introduced in 1.1.0.
Presumably your OpenSSL version is older than that and disabling OpenSSL 
(presuming you don't need it) or building against a newer version should 
help.


To disable OpenSSL e.g. "cmake ... -DCMAKE_USE_OPENSSL=false" or 
"bootstrap ... --  -DCMAKE_USE_OPENSSL=false".
To point CMake at a custom OpenSSL installation instead setting the 
CMAKE_PREFIX_PATH environment to the installation should work.


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

Re: [CMake] Visual Studio 2017 could not be found if installed in non-default location

[Nils Gladitz]

On 03/28/2017 03:57 PM, HarpyWar wrote:

"Microsoft.VisualStudio.Component.Windows81SDK" could not not be found 
anywhere.


A component "Microsoft.VisualStudio.Component.Windows10SDK.14393" 
exists on Windows 10 x64 (just found about it here 
https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-community 
)


This component also exists on a virtual machine with Windows 8.1 x86 
where cmake can not find the compiler.


vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 
-requires Microsoft.VisualStudio.Component.Windows10SDK.14393

Visual Studio Locator, version 1.0.58
Copyright (C) Microsoft Corporation. All rights reserved.


https://gitlab.kitware.com/cmake/cmake/blob/master/Source/cmVSSetupHelper.cxx#L115 
also seems to expect / accept those version suffixes.


Beyond that I can't think of anything other than debugging into 
cmVSSetupHelper.cxx.


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

Re: [CMake] Visual Studio 2017 could not be found if installed in non-default location

[Nils Gladitz]

On 03/28/2017 03:17 PM, HarpyWar wrote:

Nils Gladitz, the command, which you proposed, return nothing, even on 
a machine where a compiler found:
vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 
-requires Microsoft.VisualStudio.Component.Windows10SDK


For me it lists my "Visual Studio Community 2017" installation (on 
Windows 10).


If CMake works nonetheless perhaps you've got 
"Microsoft.VisualStudio.Component.Windows81SDK" instead of 
"Microsoft.VisualStudio.Compone

nt.Windows10SDK" (which I think CMake falls back on).

And on the systems where it doesn't work perhaps you've got neither?

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

Re: [CMake] Visual Studio 2017 could not be found if installed in non-default location

[Nils Gladitz]

On 03/26/2017 11:01 AM, HarpyWar wrote:


Output from vswhere.exe shows that Visual Studio is installed on disk C:\
(https://github.com/Microsoft/vswhere)


Perhaps also try:

vswhere -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 
-requires Microsoft.VisualStudio.Component.Windows10SDK


I think those are the default components CMake might expect when looking 
for compatible installations.


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

Re: [CMake] VS Code generator?

[Nils Gladitz]

On 03/24/2017 02:04 PM, Eric Noulard wrote:

Is there any plan to create/support a VS Code 
(https://code.visualstudio.com/) generator?


Since Visual Studio Code seems to be able to open Visual Studio 
Solution is it possible to have a working Visual Studio Generator on 
Linux?


Any information/experience about using VS Code with CMake on Linux 
would be great.


Did you see 
https://marketplace.visualstudio.com/items?itemName=vector-of-bool.cmake-tools 
?
Might have more potential with the noted CMake Server support than CMake 
generated IDE files.


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

Re: [CMake] Running test who have two labels?

[Nils Gladitz]

On 03/24/2017 11:50 AM, Eric Noulard wrote:


Hi there,

I'm playing with ctest LABELS and I wanted to know whether if it is 
possible

to run the set of tests which have 2 labels ?

I manage to have all tests which have **either** L1 or L2:

ctest -L "L1|L2"

but how can I write a proper command line for both L1 and L2 ?

apparently

ctest -L "L1" -L "L2"

only takes into account the last -L argument.



I don't think it is possible currently.
To a degree you might be able to work around it by creating additional 
labels that combine the existing ones e.g. "L1", "L2", "L1-L2".


I was pondering trying to implement test filtering based on the 
condition evaluator CMake uses for if()/while() at some point 
(cmConditionEvaluator.cxx).

e.g. --run-tests-if "L1 IN_LIST TEST_LABELS AND L2 IN_LIST TEST_LABELS"

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

Re: [CMake] can't locate library with find_library

[Nils Gladitz]

On 22.03.2017 14:52, Oliver wrote:

hi all,

I am running cmake 3 using EPEL install on RHEL 7. I also have 
installed "gflags",




$rpm -ql gflags
/usr/bin/gflags_completions.sh
/usr/lib64/libgflags.so.2.1
/usr/lib64/libgflags_nothreads.so.2.1
/usr/share/doc/gflags-2.1.1
/usr/share/doc/gflags-2.1.1/AUTHORS.txt
/usr/share/doc/gflags-2.1.1/COPYING.txt
/usr/share/doc/gflags-2.1.1/ChangeLog.txt
/usr/share/doc/gflags-2.1.1/README.txt



Did you also install the corresponding development package e.g. 
"gflags-devel"?


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

Re: [CMake] Windows mapped network drive and 'if EXISTS'

[Nils Gladitz]

On 03/03/2017 02:28 PM, Louis-Paul CORDIER wrote:



When I try to do a if(EXISTS "Z:\"), it never jump into the if statement.


Try if(EXISTS "Z:\\") or if(EXISTS "Z:/").
Either works for me.

if(EXISTS "Z:\") looks like it should have been a syntax error since the 
backslash starts an escape sequence [1].


Nils

[1] 
https://cmake.org/cmake/help/latest/manual/cmake-language.7.html#escape-sequences


--

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

Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

[Nils Gladitz]

On 22.02.2017 22:11, Malfettone, Kris wrote:


Is there a bug tracker or somewhere that I should report this as 
well?  I just want to make sure I put the right information in the 
right spot so the ninja generator maintainer might see it.




I am not sure there is a dedicated maintainer for the Ninja generator 
currently but either way the users mailing list might not be the best 
place to reach the developers.
The issue tracker is available here: 
https://gitlab.kitware.com/cmake/cmake/issues
The developers mailing list here: 
https://cmake.org/mailman/listinfo/cmake-developers


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

Re: [CMake] CMake install imported target using WIX

[Nils Gladitz]

On 02/21/2017 02:48 PM, Lars wrote:


Hello,


We are using the "config" mode of Find_Package that locates 
CompConfig.cmake which create IMPORTED targets.



CMakeLists.txt

Find_Package(some_comp ${some_comp_path})


CompConfig.cmake;

add_executable(app IMPORTED)

add_library(lib SHARED IMPORTED)


This works fine and once I read 
https://public.kitware.com/Bug/view.php?id=14311 
 I managed to get 
'make install' to include the IMPORTED targets.




What exactly did you take from the issue report?
What are your install() commands?

Everything installed by "make install" should also land in the package 
assuming what ever install logic you used honors the install time 
CMAKE_INSTALL_PREFIX as set up by CPack.


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

Re: [CMake] Response files not working with TI compilers

[Nils Gladitz]

On 02/20/2017 11:12 AM, R, Manoj wrote:


When will these changes be available in the official version of cmake.

I also made similar changes. I am suing 3.8 version of the CMake and 
the issue is not fixed.




The users mailing list might not be the ideal place to bring up issues 
like this.


You might want to report the issue here:
https://gitlab.kitware.com/cmake/cmake/issues

and/or discuss the fix on the developers mailing list:
https://cmake.org/mailman/listinfo/cmake-developers

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

Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

[Nils Gladitz]

On 15.02.2017 15:16, Malfettone, Kris wrote:


Just noticed a problem in my example.  In my attempt to simplify my 
example I moved both outputs into the same folder which in my opinion 
is invalid because both output file names are the same.  However, the 
same basic setup does reproduce the problem if you move the two 
targets into their own subdirs. I was just trying to avoid describing 
that in the email. Here is what I mean below:




I thought you meant you had a target named "test" but apparently only 
your output is named that way.

That certainly isn't covered by the existing policy.

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

Re: [CMake] Potential bug: Having executables named "test" causes Ninja generator to generate ambiguous rules...

[Nils Gladitz]

On 14.02.2017 22:53, Malfettone, Kris wrote:


If so, are executables named “test” no longer supported?
Am I missing something or wrong in some way?



Issues existed before 3.0 but since 3.0 "test" and similarly problematic 
target names have been explicitly reserved.


Any CMake Version >= 3.0 will issue a warning (when the required version 
is < 3.0) or an error (when the required version is >= 3.0) by default:

https://cmake.org/cmake/help/v3.8/policy/CMP0037.html

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

Re: [cmake-developers] [ANNOUNCE] CMake 3.8.0-rc1 now ready for testing!

[Nils Gladitz]

On 02/07/2017 07:13 PM, Robert Maynard wrote:


* The "execute_process()" command gained an "ENCODING" option to
   specify on Windows which encoding is used for output from child
   process.


Introduction of the new ENCODING option changed the implicit default 
output encoding which breaks existing code that relies on the output 
being unmodified (in my case automated tests).

This should not have been done without a new policy.

Using "ENCODING NONE" seems to fix it in my case but requires 
conditional 3.8 specific code in a project that currently has a minimum 
requirement of 3.4.


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] cmake -DX=Y -P : problem unsetting variables defined on command line

[Nils Gladitz]

On 02/09/2017 04:10 PM, Sergey Zakharchenko wrote:


cmake -DX=Y -P x.cmake


The above sets the *cache* variable X.


This x.cmake gives "X=Y":

SET(X)
MESSAGE("X=${X}")


The above unsets the *regular* variable X (leaving the cache variable X 
intact).



This, too, gives "X=Y":

UNSET(X)
MESSAGE("X=${X}")


This also unsets the *regular* variable X.
To unset the cache variable unset(X CACHE) would have worked.


This one finally gives "X=" (which I would have expected in the first place):

SET(X "")
MESSAGE("X=${X}")


Now you've got both a regular and cache variable named X.
When expanded the regular variable takes precedence.


Is this OK? Is this documented anywhere?


https://cmake.org/cmake/help/v3.7/manual/cmake-language.7.html#variables

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

Re: [CMake] CMake 3.7.2 and parallel builds

[Nils Gladitz]

On 01/30/2017 02:26 PM, Dave Flogeras wrote:

On Sun, Jan 29, 2017 at 9:53 AM, Nils Gladitz <nilsglad...@gmail.com 
<mailto:nilsglad...@gmail.com>> wrote:


FWIW I don't think -j does anything when you build the
NightlyBuild target given that that make invocation is not the one
directly performing the actual build.
The only command being run by the NightlyBuild target would be
"ctest -D NightlyBuild" (nothing to parallelize when there is only
one command).
CTest would spawn another make process for the build.

Nils


Good point, I checked with the older version of make (4.1) and even 
though it doesn't issue the warning, it is not building my project in 
parallel.


I guess that brings up the obvious question:  how does one use this 
target and take advantage of multiple processors? Basically, I'm 
calling it within a python loop that permutes various projects and 
configurations (release/debug/shared/static...) then puts the results 
on a self-hosted CDash server with make NightlySubmit.


I don't know how to do this with the generic dashboard targets ... 
assuming no one else does either you could give CTest script mode a try 
(ctest -S).
In script mode the ctest_build() command has a FLAGS option which takes 
build tool specific options like -j.


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

Re: [CMake] Adding cache entries to cmake gui

[Nils Gladitz]

On 01/30/2017 12:44 PM, Edward Diener wrote:

Using the cmake gui program of the latest cmake 3.7.2 I add a cache 
entry of CMAKE_CXX_FLAGS to some compile flag value, but as soon as I 
hit the generate button the cache entry disappears and is no longer 
retained. Is CMAKE_CXX_FLAGS no longer a valid cmake variable ? If it 
is not a valid cmake variable, what cmake variable can I use to add a 
cpp compiler flag to my cmake build ?




CMAKE_CXX_FLAGS is an advanced cache variable that should implicitly 
exist in a C++ project (it does not have to be added).

Advanced cache variables are hidden by default.
Did you check the "Advanced" option in cmake-gui?

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

Re: [CMake] CMake 3.7.2 and parallel builds

[Nils Gladitz]

On 29.01.2017 13:29, Dave Flogeras wrote:


I tried with "make -j5 VERBOSE=1 NightlyBuild" but didn't see anything 
indicative on the console, or in the cmake output files that shed any 
light for me.


What's weirder (and I forgot to mention) is that if I just build the 
project normally outside of my regression testing script (ie. "make 
-j5"), I don't get the jobserver warning.


FWIW I don't think -j does anything when you build the NightlyBuild 
target given that that make invocation is not the one directly 
performing the actual build.
The only command being run by the NightlyBuild target would be "ctest -D 
NightlyBuild" (nothing to parallelize when there is only one command).

CTest would spawn another make process for the build.

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

Re: [cmake-developers] CMake server-mode aborting

[Nils Gladitz]

On 01/26/2017 10:45 AM, Tobias Hunger wrote:


Hello CMake developers,

I have been using Qt Creator extensively with cmake server-mode for a
while now and am very happy with the results so far. Once the project
is initially configured by cmake it is really nice.

Today I started to look into a bug report that creator behaves
horribly when not all the dependencies of a project are available. In
that case the UI behaves entirely wrong (I just pushed a patch to
improve that on the Creator side into code review).

The root cause seems to be that during configure run CMake just
vanishes. Creator reports back that it crashed. I can unfortunately
not reproduce that problem with any of the CMakeLists.txt files I have
handy, so I am a bit lost at what to do.

Does any of you cmake experts have an idea what might go wrong? I
thought that maybe a MESSAGE(FATAL_ERROR ...) is triggered, causing
cmake server to terminate or something similar. Unfortunately that
does not seem to trigger the server to die for me:-/


I haven't really looked into server mode yet but for something that 
should crash cmake (server or otherwise):


function(foo)
foo()
endfunction()

foo()

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] Strange test failure

[Nils Gladitz]

On 01/20/2017 12:59 AM, Aaron Boxer wrote:


I have a test in my ctest suite that fails both with
and without a ! at the beginning of the test.

So,

FOO -BAR -BAZ

fails

and

!FOO -BAR -BAZ

fails.


I am not aware of "!" having any special meaning in the context of 
CTest. Can you elaborate?




Any ideas, or how can I get more info on the failure ?


ctest -V or ctest --output-on-failure might help.

What type of failure does CTest indicate?

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

Re: [cmake-developers] Requesting Advice: Installing object files

[Nils Gladitz]

On 17.01.2017 23:25, Chris Bieneman wrote:

Hello CMake-developers!

In one of the LLVM sub-projects we have a problem where we need to 
install object files, which doesn't seem like a particularly easy 
task. I'm curious if anyone has any advice on how to approach this 
problem.


The patch is currently being reviewed here:
https://reviews.llvm.org/D28791

Since the object files have fairly simple compile commands our current 
approach is to compile the files in custom commands, then use 
install(FILES...). This is workable, but I'm wondering if there is a 
better way. They do need to be object files, static archives would not 
work because these specially named files are handled by linkers and 
other tools that we don't control.


Also more of a workaround but perhaps you could create static libraries 
but extract them with e.g. CMAKE_AR (toolchain specific) during either 
installation e.g. install(CODE|SCRIPT) or as a POST_BUILD custom command.


An OBJECT library might be better suited in theory but I don't think it 
currently allows installation and the location of the object files is 
generator specific (and afair not always known to cmake).
By doing a manual extraction of the archive you'd be in control over 
where the objects go.


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] Add dependencies to the automoc/autorcc target?

[Nils Gladitz]

On 01/17/2017 12:02 PM, Yves Frederix wrote:


Hi all,

I have a situation in which I would need to define a dependency for
the automoc target. Is it possible to do this somehow?


https://cmake.org/cmake/help/v3.7/prop_tgt/AUTOGEN_TARGET_DEPENDS.html

The Documentation seems to imply this is AUTOMOC specific but I think 
(like the name implies) that it probably applies to all the AUTOGEN 
variants.


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

Re: [CMake] Problem with a simple framework target on OS X

[Nils Gladitz]

On 01/16/2017 11:02 AM, Nat! wrote:


Hi

I am trying to create an OS X framework with resources and headers using
cmake. This is my `CMakeLists.txt` file:

 project( Foo)

 cmake_minimum_required (VERSION 3.7)

 add_library( Foo SHARED
 foo.c
 )

 set_target_properties( Foo PROPERTIES
 FRAMEWORK TRUE
 RESOURCE "foo.md"
 PUBLIC_HEADER "foo.h"
 )


When I run `( mkdir build ; cd build ; cmake .. ; make)` a
`Foo.framework` is generated, but the header and the resource do not
appear in it. What am I missing ? (cmake version 3.7.1)


Try add_library( Foo SHARED foo.c foo.h foo.md).
From what I remember the target properties in this case only apply to 
sources that are associated with the target.


Unrelated but cmake_minimum_required() should come before project().

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

Re: [CMake] Does target order matter for dependencies?

[Nils Gladitz]

On 12/08/2016 04:01 PM, Robert Dailey wrote:


When I define my targets (custom, library, executable), does the order
of their declaration matter when it comes to using those targets in
dependencies? It's difficult to explain, so I'll show an example:


add_executable(foo main1.cpp)
target_link_libraries(foo abc)

add_library(abc main2.cpp)

In the example above, the add_library() happens after
target_link_libraries() for the executable. I've seen this work, but I
was using static libraries. Would this work for shared libraries too?


Yes, that is fine.


Does CMake do a multi-pass parse so that all targets are known prior
to them being referenced?


The link-dependencies are evaluated at generation time after your cmake 
code has been fully parsed.

At that time all targets are known.



The target_link_libraries() [1] documentation states:

"The named target must be created by add_library() within the project
or as an IMPORTED library. If it is created within the project an
ordering dependency will automatically be added in the build system to
make sure the named library target is up-to-date before the 
links."

I'm not sure what "up-to-date" here means, or if this specific
documentation is talking about compile-time dependencies or cmake
dependencies.


It means CMake makes sure the generated build system fully builds "abc" 
before it starts building "foo" (which isn't always strictly required 
but how it is currently implemented).


e.g. if "abc" has custom commands that generate header files that "foo" 
also depends on this will make sure they are created/updated before 
"foo" makes use of them.


And more obviously "abc"'s library output is created/updated before 
"foo" tries to link to it.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 11/09/2016 09:06 PM, Ruslan Baratov wrote:



So why the project in the middle of the migration process is not a valid
case? It is maintained but the exact migration step is paused, but I
have an intention to improve the code in future. Anyway even if the
project is no longer maintained, then what we have? We have
`cmake_minimum_required` with the version that fits **features** the
code has and `cmake_policy` to control the **behavior** of different
cmake versions.


Temporary use during migration to a new CMake version is one of the use 
cases explicitly mentioned in the documentation.
But when you say you might migrate some time in the future that makes it 
sound like you aren't actually in the process of migration but are 
rather looking for some loophole.





Or as I said cmake's testsuite.

If you insist on actual code e.g. this is part of the tests that I
wrote for CMP0054:
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master


The internal CMake stuff is out of the scope of discussion. If policies
are the internals why do we need them in the documentation?


Well you could have excluded the case when I brought it up initially 
preferably before asking for code.

I don't have any unmaintained public projects in mind that I could link to.
But then again as I said before the code itself is entirely irrelevant; 
what counts is the context.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 15:52, Ruslan Baratov wrote:
Can you show the real code? The code that in your opinion doesn't 
violate the "right way of policy usage"?


It is not a question about code. It is a question about context and use 
case.


Valid context as the documentation states would e.g. be a project that 
is no longer maintained where you have no intention of ever migrating to 
a newer CMake version.

Or as I said cmake's testsuite.

If you insist on actual code e.g. this is part of the tests that I wrote 
for CMP0054:

https://cmake.org/gitweb?p=cmake.git;a=blob;f=Tests/RunCMake/CMP0054/CMP0054-NEW.cmake;h=23a912476024ba09fcf741e04f999b64a6e91450;hb=refs/heads/master

Again the code itself is irrelevant here; what matters is the context.

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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 14:57, Ruslan Baratov wrote:


Again policies are not meant to be feature toggles.
You can do a lot of things and there may be valid use cases but in 
general policies are not meant to be used this way.

This is made explicit in CMake's documentation on policies.
They exist to preserve backwards compatibility not to pick and choose 
behaviours.


So can you show an example of "valid" use of `cmake_policy` command?



To quote the documentation:
"A policy is a deprecation mechanism and not a reliable feature toggle. 
A policy should almost never be set to |OLD|, except to silence warnings 
in an otherwise frozen or stable codebase, or temporarily as part of a 
larger migration path."


Beyond that valid use would be e.g. cmake's own testsuite which needs to 
be able to toggle individual policies to verify their behaviour.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 12:04, Ruslan Baratov wrote:

On 09-Nov-16 16:22, Nils Gladitz wrote:

On 09.11.2016 04:29, Ruslan Baratov wrote:

On 08-Nov-16 23:33, Nils Gladitz wrote:

On 11/08/2016 04:17 PM, Ruslan Baratov wrote:


Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior.


I don't agree and you can not separate the two.
cmake_minimum_required() initializes the policies based on the 
given version.
So what? From the user's perspective the "initialization of 
policies" is like a syntactic sugar so you don't have to write 
endless `cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal 
with them further.


You can't simultaneously argue that cmake_minimum_required() isn't 
about policies (behaviours) and at the same time syntactic sugar for 
those very same policies.

You're playing with words instead of using arguments.


There was no word play involved.
You say cmake_minimum_required() is not about behaviour yet it 
initializes all policies which are purely about behaviour.






Policy warnings aren't meant to indicate errors in your code but 
changes in behaviour that will happen if you were to increase your 
minimum required version.
Policy CMP0038 doesn't agree with you: 
https://cmake.org/cmake/help/latest/policy/CMP0038.html


No policies are still primarily about behaviour changes. That is true 
for CMP0038 as well.


The old behaviour is to ignore this issue in user code. The new 
behaviour is to produce an error.
When maintainers get this warning they are informed that their code will 
break as soon as they increase their minimum required version.


The same is true for CMP0054. The policy warning did find many errors in 
user code but the warning is primarily about the change in behaviour.



Yes, like this:

cmake_minimum_required(VERSION  2.8)
project(foo)

if(POLICY CMP0038)cmake_policy(SET CMP0038 OLD) endif()

Now CMake 3.0 users will not see the warning and CMake 2.8 users 
**don't have to upgrade**.


Yes but I don't see what point you are trying to make ... they didn't 
have to upgrade without the explicit policy set either.
And the policy warnings aren't meant for users they are meant for 
maintainers.



In fact all that setting it to OLD does is suppress the warning.

Actually this statement is wrong. Take a look at this example:

# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(fooVERSION 1.2.3)
cmake_policy(SET CMP0038 OLD) # Do not remove this!
add_library(foofoo.cpp)
target_link_libraries(foofoo)

if you remove `cmake_policy(SET CMP0038 OLD)` this example will 
produce **error**. It may happens when you want to use new **feature** 
`project(VERSION)` from 3.0, hence you set 
`cmake_minimum_required(VERSION 3.0)` and simultaneously you have code 
which produce warning about CMP0038. By setting `cmake_policy(SET 
CMP0038 OLD)` you suppress the error, i.e. change **behaviour**.


You took this out of context. I was talking about your second example 
about CMP0054 which was unset by cmake_minimum_required(VERSION 2.8) and 
then explicitly set to OLD by you.
In this new case you have a policy that is initialized to NEW by 
cmake_minimum_required(VERSION 3.0) and then set to OLD by you.


Policies are not meant to be feature toggles. You are explicitly asking 
CMake to use deprecated behaviour (that should no longer be used and 
might be removed in the future) over new behaviour.




It's better than emitting zillion of warnings to the output, right? 
You can suppress one type and fix another, set TODOs, etc.


Policy warnings are intended to encourage you to switch to new 
behaviours since the old ones are deprecated.

In actively maintained projects they are not meant to be suppressed.
Why not? If you're not planning to fix them right now? I'm not saying 
you have to ignore them, you have to do fixes, but why not suppress 
and say work on other fixes?


Like I said policies are not primarily about fixing code. They are about 
migrating to new behaviours introduced by new versions of CMake.




And this code will produce "FOO":

cmake_minimum_required(VERSION 3.1)

cmake_policy(SET CMP0054 OLD) # behave like 3.0

set(ONE 1)

if(1 STREQUAL "ONE")
  message("FOO")
else()
  message("BAR")
endif()

In this example by `cmake_minimum_required(VERSION 3.1)` you telling 
user that you're planning to use some **feature** from CMake 3.1. 


Again I disagree. cmake_minimum_required(VERSION 3.1) tells CMake to 
behave like 3.1. It does not indicate that you want to use any 3.1 
specific features.


This feature may be about interpreting differently `if(1 STREQUAL 
"ONE")` and `if(1 STREQUAL ONE)` or may be about anything else. Note 
that CMake 3.0 **has no such feature** and commands  `if(1 STREQUAL 
"ONE")` /`if(1 STREQUAL ONE)` is same for him always. Policy CMP0054 
is abo

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 03:47, Ruslan Baratov wrote:

On 09-Nov-16 06:01, Nils Gladitz wrote:

I think the git tag creation dates should roughly equate release dates:
 https://cmake.org/gitweb?p=cmake.git;a=tags

What about the future releases? There was a page
https://cmake.org/Bug/changelog_page.php before but it's no longer valid
as far as I understand.


https://gitlab.kitware.com/cmake/cmake/milestones

I wouldn't consider those dates to be anything but very rough estimates 
though.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 09.11.2016 04:29, Ruslan Baratov wrote:

On 08-Nov-16 23:33, Nils Gladitz wrote:

On 11/08/2016 04:17 PM, Ruslan Baratov wrote:


Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior.


I don't agree and you can not separate the two.
cmake_minimum_required() initializes the policies based on the given 
version.
So what? From the user's perspective the "initialization of policies" 
is like a syntactic sugar so you don't have to write endless 
`cmake_policy(SET CMP00xx NEW)`. Nothing to do how to deal with them 
further.


You can't simultaneously argue that cmake_minimum_required() isn't about 
policies (behaviours) and at the same time syntactic sugar for those 
very same policies.







  If you have command
`if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
it will work with CMake 2.8. However if you have warning about policy
CMP0054 (since CMake 3.2) you can set policy to old without changing
`cmake_minimum_required` (hence without forcing your CMake 2.8 users to
upgrade to CMake 3.2).


Coincidentally I implemented both of those policies :)

Given your second example you likely shouldn't be touching the policy 
at all.
I have to. If my code use features from CMake 2.8 I do set 
`cmake_minimum_required(VERSION 2.8)`. But some users may have CMake 
3.2 installed. Do they must downgrade CMake? Of course not. But if I'm 
not touching policies there will be warnings around. If I'm good 
developer I will investigate the root of the warnings and fix them. 
Actually most of them will be about bugs in my code or dangerous 
behavior, so it does improve 2.8 too.


Policy warnings aren't meant to indicate errors in your code but changes 
in behaviour that will happen if you were to increase your minimum 
required version.
As such they can often be worked around by using behaviour that is 
consistent between versions but they are not meant to indicate errors to 
be fixed.


Instead they are meant to encourage you to embrace the new behaviours 
and abandon the old (which will require porting work) since the old are 
by definition deprecated and may be removed in the future (though so far 
CMake has been very conservative about this).






A policy warning does not force your users to use a new CMake version.

Well that's what I said.


You said you are not forcing your users to upgrade by setting a policy 
to OLD.
Which implied that not setting the policy to OLD would force your users 
to upgrade ... which it doesn't.





In fact all that setting it to OLD does is suppress the warning.
It's better than emitting zillion of warnings to the output, right? 
You can suppress one type and fix another, set TODOs, etc.


Policy warnings are intended to encourage you to switch to new 
behaviours since the old ones are deprecated.

In actively maintained projects they are not meant to be suppressed.




CMake will use the old behavior in either case.

The warnings guide developers when they do bump their 
cmake_minimum_required(VERSION).
By just suppressing it behavior changes might go unnoticed when the 
bump does happen.
There are 3 components in the equation: the **real** CMake version, 
the version in `cmake_minimum_required` and the default policies for 
such version. Can you provide an example of what you mean?


cmake_minimum_required(VERSION 3.0)

set(ONE 1)

if(1 STREQUAL "ONE")
message("FOO")
else()
message("BAR")
endif()

This code was designed for 3.0 (as indicated by the 
cmake_minimum_required(VERSION)) and is meant to output "FOO".

When you use CMake 3.0 that is the behaviour you get (without warnings).
When you use CMake >= 3.1 the behaviour of the code itself is still the 
same but you will get a CMP0054 warning telling you that the behaviour 
that you currently depend on in if() has been deprecated.


Now you decide to bump your minimum required version from 3.0 to 3.1 and 
ignore or suppress the policy warning from before:


cmake_minimum_required(VERSION 3.1)

set(ONE 1)

if(1 STREQUAL "ONE")
message("FOO")
else()
message("BAR)
endif()

Now when you use CMake >= 3.1 to run this code you will not get any more 
warnings but it will also no longer behave like it used to.


It will output "BAR" instead of "FOO".


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 08.11.2016 20:26, Albrecht Schlosser wrote:

On 08.11.2016 15:22 Nils Gladitz wrote:


Strictly speaking cmake_minimum_required(VERSION) is not about command
availability but rather about behavior (cmake policies).

[...]

I'd start by requesting the highest possible version I could justify
(e.g. based on availability on target platforms and user convenience)
and then start from there.


And that's exactly the (my) point. How can I find out the "highest 
possible version I could justify"?


I'm a developer of a public GUI library (FLTK). In this position you 
don't know anything about the availability of CMake versions on your 
target platforms. Our intention is to keep cmake_minimum_required() as 
low as possible.




If you are intending to keep the required version as low as possible 
you'll already have a justification / reason for doing so.
I can only assume that the reason is that you need to support ancient 
platforms which ship equally ancient versions of CMake and you don't 
want to bother your users to build or install custom newer versions of 
CMake.


It doesn't matter what your reasons or justifications for it are (though 
I would hope they are valid and verified) but you have to decide on a 
minimum version that you can life with in the end.


That said, whenever you change a CMakeLists.txt file you should be 
aware if the commands you use are compatible with the CMake version 
you "require". There should be an easy way to find out in which 
version a particular CMake command has been introduced. Only with this 
information you can decide if you should use this fine command or 
better find another way to do the task you're going to do.


At this point you only have to refer to the documentation that actually 
corresponds to the version you decided to require.
You'll only find commands and behaviours in that documentation that'll 
actually be available in your minimum version.
You will not find commands or behaviours that are unavailable in your 
version so you will not be tempted to use them nor will you have to 
asses them individually for their availability.




I'd like to have a list of release dates (I'm not sure if there is 
one) as well as the exact version a feature was introduced to write 
CMakeLists.txt files that run on really old CMake versions.




I think the git tag creation dates should roughly equate release dates:
https://cmake.org/gitweb?p=cmake.git;a=tags

Note: currently we have cmake_minimum_required(VERSION 2.6.3) (sic!), 
but we also have conditional code for some higher CMake versions:


2.6.3's tag e.g. "Sat, 21 Feb 2009 19:43:45 + (14:43 -0500)" would 
be over 7 years old now.




if(CMAKE_VERSION VERSION_GREATER 2.8.4) ...
if(NOT CMAKE_VERSION VERSION_LESS 3.0.0) ...



There are exceptions to every rule but I'd personally avoid or at least 
try to minimize such constructs if possible.


CMake's policy mechanism tries hard to preserve old behaviours so that 
existing projects depending on those old behaviours don't break with new 
versions of CMake.
Given your minimum required version CMake 3.7 will still mostly try to 
behave like 2.6.3.


With constructs like these this is no longer the case and you need an 
increasing number of CMake versions to get proper coverage.
Developers that use one specific version of CMake can not longer be 
reasonably confident that their CMake script changes also work on other 
versions of CMake covered by distinct version specific conditionals.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 11/08/2016 04:17 PM, Ruslan Baratov wrote:


On 08-Nov-16 22:22, Nils Gladitz wrote:

Strictly speaking cmake_minimum_required(VERSION) is not about command
availability but rather about behavior (cmake policies).

Except it's exactly opposite :) `cmake_minimum_required` is about new
features/commands, and policies is about behavior.


I don't agree and you can not separate the two.
cmake_minimum_required() initializes the policies based on the given 
version.



  If you have command
`if(IN_LIST)` since 3.3 you can't manipulate policies in such way that
it will work with CMake 2.8. However if you have warning about policy
CMP0054 (since CMake 3.2) you can set policy to old without changing
`cmake_minimum_required` (hence without forcing your CMake 2.8 users to
upgrade to CMake 3.2).


Coincidentally I implemented both of those policies :)

Given your second example you likely shouldn't be touching the policy at 
all.


A policy warning does not force your users to use a new CMake version.
In fact all that setting it to OLD does is suppress the warning.
CMake will use the old behavior in either case.

The warnings guide developers when they do bump their 
cmake_minimum_required(VERSION).
By just suppressing it behavior changes might go unnoticed when the bump 
does happen.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 11/08/2016 03:11 PM, Dvir Yitzchaki wrote:


But how do you know which version to declare on cmake_minimum_required?
If this feature will be added it won't be far from writing a script that scans 
the commands you use and outputs the first appropriate version.



Strictly speaking cmake_minimum_required(VERSION) is not about command 
availability but rather about behavior (cmake policies).
CMake does not diagnose or prevent use of commands that were introduced 
after the current policy version.


No automation can detect which behaviors you might expect or require 
based on the commands you are using.


I'd start by requesting the highest possible version I could justify 
(e.g. based on availability on target platforms and user convenience) 
and then start from there.
For existing projects policy warnings help migrating to newer behaviors 
and versions as they become available / justifiable.


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

Re: [CMake] Adding Cmake version in online documentation

[Nils Gladitz]

On 11/08/2016 10:57 AM, Louis-Paul CORDIER wrote:


Hi,

This is a feature proposal for the documentation. Cmake is making use 
of cmake_minimum_required() command, that is very useful. 
Unfortunately it is very hard to identify commands that will work 
without browsing all version of cmake documentation for a given command.




This has been brought up for discussion more than once e.g.:
https://public.kitware.com/Bug/view.php?id=15517
https://public.kitware.com/Bug/view.php?id=15222
http://public.kitware.com/pipermail/cmake/2016-April/063306.html

Personally I still don't think this needs change.
You don't have to browse all versions of the documentation ... you only 
have to work with the documentation that matches the version you 
declared in cmake_minimum_required().


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

Re: [CMake] CPACK WIX shortcuts

[Nils Gladitz]

On 03.11.2016 19:32, Tiago Macarios wrote:



And I am building it like so:
mkdir build
cd build
cmake ..
cmake --build . --config Release
cpack -G WIX


You are using a multi-configuration generator (Visual Studio).

As you do in the build try specifying a configuration to be packaged 
when invoking cpack (the "PACKAGE" target that cmake generates does this 
by default):

e.g. cpack -C Release -G WIX

The install properties are only generated for the known configurations.

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

Re: [CMake] CPACK WIX shortcuts

[Nils Gladitz]

On 11/03/2016 12:23 AM, Tiago Macarios wrote:


Hi,

I am trying to create an installer with CPACK and WIX as generator. 
Everything works fine except that I cannot get start menu shortcuts to 
work.


I was using almost the same code as the link below (which seems to be 
the unit tests for this feature), then I tried to build the unit test 
and I still don't see the shortcut directives on the wix files.


Am I doing something wrong, or is this a regression?


Which CMake version are you actually using?
This feature was implemented in CMake 3.3.0.



https://github.com/ngladitz/cmake-wix-testsuite/blob/d01013e2066e68088b4f56a8ab7750eb3cea7089/property_start_menu_shortcuts/CMakeLists.txt


This still works for me using CMake 3.7.0-rc2.

CMake 3.7.0-rc2's own windows installer uses the same feature for the 
start menu shortcut to the documentation which also seems to work for me.


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

Re: [cmake-developers] Is there a way in CMake to get a list of all CTest tests added with add_test?

[Nils Gladitz]

On 04.10.2016 11:20, Tobias Hunger wrote:

On Mo, 2016-10-03 at 14:25 -0400, Brad King wrote:

The list we need would thus be built up to contain all COMMAND
arguments to add_test that are also build targets in CMake.

The list would also need to include targets mentioned in generator
expressions such as `$`.  This will almost certainly
be better done as a CMake feature implemented in C++.  This was actually
an early design philosophy: do the hard stuff in C++ so that complex
logic is not needed in CMake-language code.

Access to the list of defined tests would be nice to have in the server-mode,
too:-)

If some work is done in that direction, please keep server-mode in mind when
designing the APIs. I would love to reuse them to expose that information to
clients.


This might be rare but the tests that cmake knows about might differ 
from the tests that ctest knows about given that tests can be 
dynamically defined through TEST_INCLUDE_FILE[1].


I've never used it that way but I was considering e.g. querying test 
binaries (produced at build time) for the tests they define and making 
those available dynamically when ctest processes CTestTestfile.cmake. 
This is in contrast to e.g. FindGTests.cmake's GTEST_ADD_TESTS() which 
tries to accomplish the same thing at configuration time by parsing test 
sources instead.


[1] https://cmake.org/cmake/help/v3.6/prop_dir/TEST_INCLUDE_FILE.html

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] [cmake-developers] CPack [WiX] Customizations of individual features/components

[Nils Gladitz]

On 09/30/2016 08:43 AM, Roman Wüger wrote:


Hello,

I want to customize some with CPack  generated *.wxs files.

For example: directories.wxs is generated with only the TARGET_DIR.


TARGETDIR (no underscore) is always the one and only root-directory 
element [1].



How can I add an additional directory in this file and use the newly added 
directory in the components (features.wxs)?

I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it, but 
if so how?


CPACK_WIX_PATCH_FILE can be used to add XML content to (some) existing elements.
It can not be used to reorder or remove existing elements and can not be used 
to modify the attributes of existing elements.


Nils


[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372064(v=vs.85).aspx

--

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

Re: [cmake-developers] CPack [WiX] Customizations of individual features/components

[Nils Gladitz]

On 09/30/2016 08:43 AM, Roman Wüger wrote:


Hello,

I want to customize some with CPack  generated *.wxs files.

For example: directories.wxs is generated with only the TARGET_DIR.


TARGETDIR (no underscore) is always the one and only root-directory 
element [1].



How can I add an additional directory in this file and use the newly added 
directory in the components (features.wxs)?

I read about CPACK_WIX_PATCH_FILE. Maybe it is possible to do so with it, but 
if so how?


CPACK_WIX_PATCH_FILE can be used to add XML content to (some) existing elements.
It can not be used to reorder or remove existing elements and can not be used 
to modify the attributes of existing elements.


Nils


[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372064(v=vs.85).aspx

--

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-commits] CMake branch, next, updated. v3.6.2-1960-g5ba3f1a

[Nils Gladitz]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  5ba3f1a9068a6504c8a3ae5987a090c6fe787b40 (commit)
   via  b35311ca44b7e8b40cc48aaac6cefbe8ca4ddba8 (commit)
  from  b727346b4081504076b8fd48550325fa7eb31496 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5ba3f1a9068a6504c8a3ae5987a090c6fe787b40
commit 5ba3f1a9068a6504c8a3ae5987a090c6fe787b40
Merge: b727346 b35311c
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Mon Sep 12 13:41:35 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Sep 12 13:41:35 2016 -0400

Merge topic 'fix-ctest-segfault' into next

b35311ca CTestSVN: Fix segfault when CTEST_UPDATE_VERSION_ONLY is enabled


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b35311ca44b7e8b40cc48aaac6cefbe8ca4ddba8
commit b35311ca44b7e8b40cc48aaac6cefbe8ca4ddba8
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Mon Sep 12 18:29:08 2016 +0200
Commit: Nils Gladitz <nilsglad...@gmail.com>
CommitDate: Mon Sep 12 19:40:13 2016 +0200

CTestSVN: Fix segfault when CTEST_UPDATE_VERSION_ONLY is enabled

Before the change the list of externals was queried only
before the svn update.

With the change the list is queried both before and after.
This should also be more accurate since the list of externals might
change during the update.

diff --git a/Source/CTest/cmCTestSVN.cxx b/Source/CTest/cmCTestSVN.cxx
index f680612..0832820 100644
--- a/Source/CTest/cmCTestSVN.cxx
+++ b/Source/CTest/cmCTestSVN.cxx
@@ -108,13 +108,8 @@ std::string cmCTestSVN::LoadInfo(SVNInfo& svninfo)
 
 void cmCTestSVN::NoteOldRevision()
 {
-  // Info for root repository
-  this->Repositories.push_back(SVNInfo(""));
-  this->RootInfo = &(this->Repositories.back());
-  // Info for the external repositories
-  this->LoadExternals();
+  this->LoadRepositories();
 
-  // Get info for all the repositories
   std::list::iterator itbeg = this->Repositories.begin();
   std::list::iterator itend = this->Repositories.end();
   for (; itbeg != itend; itbeg++) {
@@ -134,7 +129,8 @@ void cmCTestSVN::NoteOldRevision()
 
 void cmCTestSVN::NoteNewRevision()
 {
-  // Get info for the external repositories
+  this->LoadRepositories();
+
   std::list::iterator itbeg = this->Repositories.begin();
   std::list::iterator itend = this->Repositories.end();
   for (; itbeg != itend; itbeg++) {
@@ -534,8 +530,13 @@ private:
   }
 };
 
-void cmCTestSVN::LoadExternals()
+void cmCTestSVN::LoadRepositories()
 {
+  // Info for root repository
+  this->Repositories.clear();
+  this->Repositories.push_back(SVNInfo(""));
+  this->RootInfo = &(this->Repositories.back());
+
   // Run "svn status" to get the list of external repositories
   std::vector svn_status;
   svn_status.push_back("status");
diff --git a/Source/CTest/cmCTestSVN.h b/Source/CTest/cmCTestSVN.h
index 6f2374d..2301b10 100644
--- a/Source/CTest/cmCTestSVN.h
+++ b/Source/CTest/cmCTestSVN.h
@@ -86,7 +86,7 @@ private:
   SVNInfo* RootInfo;
 
   std::string LoadInfo(SVNInfo& svninfo);
-  void LoadExternals();
+  void LoadRepositories();
   void LoadModifications() CM_OVERRIDE;
   void LoadRevisions() CM_OVERRIDE;
   void LoadRevisions(SVNInfo& svninfo);

---

Summary of changes:
 Source/CTest/cmCTestSVN.cxx |   17 +
 Source/CTest/cmCTestSVN.h   |2 +-
 2 files changed, 10 insertions(+), 9 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

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

[Nils Gladitz]

On 09/09/2016 10:54 AM, Stuermer, Michael SP/HZA-ZSEP wrote:



The details you miss if you are not using the features ... thanks for the hint, 
here is corrected patch.

Michael


Thanks. I merged to "next" with small changes.

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-commits] CMake branch, next, updated. v3.6.2-1888-g9753c73

[Nils Gladitz]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  9753c73bcf72c2dbba11c93406501126e93a5baa (commit)
   via  c0bccc51df0eda22b4a7aa5833e1204412b39fc8 (commit)
  from  804588e64dcbe7075d4272edd26975bf76a435d5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9753c73bcf72c2dbba11c93406501126e93a5baa
commit 9753c73bcf72c2dbba11c93406501126e93a5baa
Merge: 804588e c0bccc5
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Fri Sep 9 07:04:10 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Sep 9 07:04:10 2016 -0400

Merge topic 'wix-feature-patch' into next

c0bccc51 CPackWIX: Enabled patching of WIX  tags


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c0bccc51df0eda22b4a7aa5833e1204412b39fc8
commit c0bccc51df0eda22b4a7aa5833e1204412b39fc8
Author: Michael Stürmer <michael.stuer...@schaeffler.com>
AuthorDate: Fri Sep 9 10:53:26 2016 +0200
Commit: Nils Gladitz <nilsglad...@gmail.com>
CommitDate: Fri Sep 9 13:03:57 2016 +0200

CPackWIX: Enabled patching of WIX  tags

diff --git a/Help/release/dev/wix-feature-patch.rst 
b/Help/release/dev/wix-feature-patch.rst
new file mode 100644
index 000..0b1cbe3
--- /dev/null
+++ b/Help/release/dev/wix-feature-patch.rst
@@ -0,0 +1,5 @@
+wix-feature-patch
+-
+
+* The CPack WIX generator now supports
+  CPACK_WIX_PATCH_FILE fragments for Feature elements.
diff --git a/Modules/CPackWIX.cmake b/Modules/CPackWIX.cmake
index 08ff0cb..d02df2d 100644
--- a/Modules/CPackWIX.cmake
+++ b/Modules/CPackWIX.cmake
@@ -147,7 +147,7 @@
 # }
 #
 #  Currently fragments can be injected into most
-#  Component, File and Directory elements.
+#  Component, File, Directory and Feature elements.
 #
 #  The following additional special Ids can be used:
 #
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 85e0ae3..ba5787e 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -628,7 +628,7 @@ bool cmCPackWIXGenerator::CreateFeatureHierarchy(
i != ComponentGroups.end(); ++i) {
 cmCPackComponentGroup const& group = i->second;
 if (group.ParentGroup == 0) {
-  featureDefinitions.EmitFeatureForComponentGroup(group);
+  featureDefinitions.EmitFeatureForComponentGroup(group, *this->Patch);
 }
   }
 
@@ -638,7 +638,7 @@ bool cmCPackWIXGenerator::CreateFeatureHierarchy(
 cmCPackComponent const& component = i->second;
 
 if (!component.Group) {
-  featureDefinitions.EmitFeatureForComponent(component);
+  featureDefinitions.EmitFeatureForComponent(component, *this->Patch);
 }
   }
 
diff --git a/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx 
b/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx
index 7794935..c9f17cc 100644
--- a/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx
+++ b/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx
@@ -42,7 +42,7 @@ void 
cmWIXFeaturesSourceWriter::CreateCMakePackageRegistryEntry(
 }
 
 void cmWIXFeaturesSourceWriter::EmitFeatureForComponentGroup(
-  cmCPackComponentGroup const& group)
+  cmCPackComponentGroup const& group, cmWIXPatch& patch)
 {
   BeginElement("Feature");
   AddAttribute("Id", "CM_G_" + group.Name);
@@ -57,20 +57,22 @@ void 
cmWIXFeaturesSourceWriter::EmitFeatureForComponentGroup(
   for (std::vector<cmCPackComponentGroup*>::const_iterator i =
  group.Subgroups.begin();
i != group.Subgroups.end(); ++i) {
-EmitFeatureForComponentGroup(**i);
+EmitFeatureForComponentGroup(**i, patch);
   }
 
   for (std::vector<cmCPackComponent*>::const_iterator i =
  group.Components.begin();
i != group.Components.end(); ++i) {
-EmitFeatureForComponent(**i);
+EmitFeatureForComponent(**i, patch);
   }
 
+  patch.ApplyFragment("CM_G_" + group.Name, *this);
+
   EndElement("Feature");
 }
 
 void cmWIXFeaturesSourceWriter::EmitFeatureForComponent(
-  cmCPackComponent const& component)
+  cmCPackComponent const& component, cmWIXPatch& patch)
 {
   BeginElement("Feature");
   AddAttribute("Id", "CM_C_" + component.Name);
@@ -90,6 +92,8 @@ void cmWIXFeaturesSourceWriter::EmitFeatureForComponent(
 AddAttribute("Level", "2");
   }
 
+  patch.ApplyFragment("CM_C_" + component.Name, *this);
+
   EndElement("Feature");
 }
 
diff --git a/Source/CPack/WiX/cmWIXFeaturesSourceWrite

[Cmake-commits] CMake branch, next, updated. v3.6.2-1886-g804588e

[Nils Gladitz]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  804588e64dcbe7075d4272edd26975bf76a435d5 (commit)
   via  c17b7f72344fbd328c66d01689e47f1520677bef (commit)
  from  740f009e4c4ad8b532f7b4e478d0863d4be1ce6a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=804588e64dcbe7075d4272edd26975bf76a435d5
commit 804588e64dcbe7075d4272edd26975bf76a435d5
Merge: 740f009 c17b7f7
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Fri Sep 9 07:03:45 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Sep 9 07:03:45 2016 -0400

Merge topic 'wix-feature-patch' into next

c17b7f72 !fixup: Add missing topic release note


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c17b7f72344fbd328c66d01689e47f1520677bef
commit c17b7f72344fbd328c66d01689e47f1520677bef
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Fri Sep 9 13:03:19 2016 +0200
Commit: Nils Gladitz <nilsglad...@gmail.com>
CommitDate: Fri Sep 9 13:03:19 2016 +0200

!fixup: Add missing topic release note

diff --git a/Help/release/dev/wix-feature-patch.rst 
b/Help/release/dev/wix-feature-patch.rst
new file mode 100644
index 000..0b1cbe3
--- /dev/null
+++ b/Help/release/dev/wix-feature-patch.rst
@@ -0,0 +1,5 @@
+wix-feature-patch
+-
+
+* The CPack WIX generator now supports
+  CPACK_WIX_PATCH_FILE fragments for Feature elements.

---

Summary of changes:
 Help/release/dev/wix-feature-patch.rst |5 +
 1 file changed, 5 insertions(+)
 create mode 100644 Help/release/dev/wix-feature-patch.rst


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.2-1884-g740f009

[Nils Gladitz]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  740f009e4c4ad8b532f7b4e478d0863d4be1ce6a (commit)
   via  0259faf1e8b19b72f54645817a0b4cd146d9ca26 (commit)
   via  d62a5dfc86a4d0f48f93494065f7a835c9140bb6 (commit)
  from  59edc3fb74ca1eb857601c63bb01c682c1a8466b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=740f009e4c4ad8b532f7b4e478d0863d4be1ce6a
commit 740f009e4c4ad8b532f7b4e478d0863d4be1ce6a
Merge: 59edc3f 0259faf
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Fri Sep 9 06:40:11 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Fri Sep 9 06:40:11 2016 -0400

Merge topic 'wix-feature-patch' into next

0259faf1 CPackWIX: Enabled patching of WIX  tags
d62a5dfc CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0259faf1e8b19b72f54645817a0b4cd146d9ca26
commit 0259faf1e8b19b72f54645817a0b4cd146d9ca26
Author: Michael Stürmer <michael.stuer...@schaeffler.com>
AuthorDate: Fri Sep 9 10:53:26 2016 +0200
Commit: Nils Gladitz <nilsglad...@gmail.com>
CommitDate: Fri Sep 9 11:34:43 2016 +0200

CPackWIX: Enabled patching of WIX  tags

diff --git a/Modules/CPackWIX.cmake b/Modules/CPackWIX.cmake
index 08ff0cb..d02df2d 100644
--- a/Modules/CPackWIX.cmake
+++ b/Modules/CPackWIX.cmake
@@ -147,7 +147,7 @@
 # }
 #
 #  Currently fragments can be injected into most
-#  Component, File and Directory elements.
+#  Component, File, Directory and Feature elements.
 #
 #  The following additional special Ids can be used:
 #
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 85e0ae3..ba5787e 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -628,7 +628,7 @@ bool cmCPackWIXGenerator::CreateFeatureHierarchy(
i != ComponentGroups.end(); ++i) {
 cmCPackComponentGroup const& group = i->second;
 if (group.ParentGroup == 0) {
-  featureDefinitions.EmitFeatureForComponentGroup(group);
+  featureDefinitions.EmitFeatureForComponentGroup(group, *this->Patch);
 }
   }
 
@@ -638,7 +638,7 @@ bool cmCPackWIXGenerator::CreateFeatureHierarchy(
 cmCPackComponent const& component = i->second;
 
 if (!component.Group) {
-  featureDefinitions.EmitFeatureForComponent(component);
+  featureDefinitions.EmitFeatureForComponent(component, *this->Patch);
 }
   }
 
diff --git a/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx 
b/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx
index 7794935..c9f17cc 100644
--- a/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx
+++ b/Source/CPack/WiX/cmWIXFeaturesSourceWriter.cxx
@@ -42,7 +42,7 @@ void 
cmWIXFeaturesSourceWriter::CreateCMakePackageRegistryEntry(
 }
 
 void cmWIXFeaturesSourceWriter::EmitFeatureForComponentGroup(
-  cmCPackComponentGroup const& group)
+  cmCPackComponentGroup const& group, cmWIXPatch& patch)
 {
   BeginElement("Feature");
   AddAttribute("Id", "CM_G_" + group.Name);
@@ -57,20 +57,22 @@ void 
cmWIXFeaturesSourceWriter::EmitFeatureForComponentGroup(
   for (std::vector<cmCPackComponentGroup*>::const_iterator i =
  group.Subgroups.begin();
i != group.Subgroups.end(); ++i) {
-EmitFeatureForComponentGroup(**i);
+EmitFeatureForComponentGroup(**i, patch);
   }
 
   for (std::vector<cmCPackComponent*>::const_iterator i =
  group.Components.begin();
i != group.Components.end(); ++i) {
-EmitFeatureForComponent(**i);
+EmitFeatureForComponent(**i, patch);
   }
 
+  patch.ApplyFragment("CM_G_" + group.Name, *this);
+
   EndElement("Feature");
 }
 
 void cmWIXFeaturesSourceWriter::EmitFeatureForComponent(
-  cmCPackComponent const& component)
+  cmCPackComponent const& component, cmWIXPatch& patch)
 {
   BeginElement("Feature");
   AddAttribute("Id", "CM_C_" + component.Name);
@@ -90,6 +92,8 @@ void cmWIXFeaturesSourceWriter::EmitFeatureForComponent(
 AddAttribute("Level", "2");
   }
 
+  patch.ApplyFragment("CM_C_" + component.Name, *this);
+
   EndElement("Feature");
 }
 
diff --git a/Source/CPack/WiX/cmWIXFeaturesSourceWriter.h 
b/Source/CPack/WiX/cmWIXFeaturesSourceWriter.h
index 9974b63..124ed42 100644
--- a/Source/CPack/WiX/cmWIXFeaturesSourceWriter.h
+++ b/Source/CPack/WiX/cmWIXFeaturesSourceWriter.h
@@ -13,6 +13,7 @@
 #ifndef cmWIXFeaturesSourceW

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

[Nils Gladitz]

On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote:

Here it is.



The patch only seems to allow patching Features generated for components 
but not Features generated for component groups.

Is that intentional or an oversight?

I think we should allow patching for both.

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

[Nils Gladitz]

On 09/06/2016 01:26 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Yes I tried, didn't work somehow. Never mind, the current approach works.


It should have worked. I've added a new working test case to my suite:
https://github.com/ngladitz/cmake-wix-testsuite/tree/master/feature_ref_in_product

I'll look into integrating your patch for consistency nonetheless but it 
should not really have been required for your use case.


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: Bugfix for WIX support

[Nils Gladitz]

On 06.09.2016 17:19, Stuermer, Michael SP/HZA-ZSEP wrote:

I checked everything on our project. Works as expected so far. I had to add our 
CSharp patch(es) on top, so this is not a pure WIX feature test, but I think 
it's good to go.



Thanks I reformatted, squashed and merged to "next" for testing.

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-commits] CMake branch, next, updated. v3.6.1-1813-gd7cc684

[Nils Gladitz]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  d7cc6846e9bfce3f59161ee1485b181039276d6a (commit)
   via  1bc33257d48bb4b54333b755951967c6c3fa1df6 (commit)
  from  246539626a1dc8558202bd0b9a343b3e0af1f426 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d7cc6846e9bfce3f59161ee1485b181039276d6a
commit d7cc6846e9bfce3f59161ee1485b181039276d6a
Merge: 2465396 1bc3325
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Tue Sep 6 11:45:58 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Tue Sep 6 11:45:58 2016 -0400

Merge topic 'wix-fix-static-prefix' into next

1bc33257 CPackWIX: Fix incomplete CPACK_WIX_SKIP_PROGRAM_FOLDER 
implementation


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1bc33257d48bb4b54333b755951967c6c3fa1df6
commit 1bc33257d48bb4b54333b755951967c6c3fa1df6
Author: Michael Stürmer <michael.stuer...@schaeffler.com>
AuthorDate: Tue Sep 6 12:11:00 2016 +0200
Commit: Nils Gladitz <nilsglad...@gmail.com>
CommitDate: Tue Sep 6 17:44:48 2016 +0200

CPackWIX: Fix incomplete CPACK_WIX_SKIP_PROGRAM_FOLDER implementation

Commit 17bbf6af (CPackWIX: Implement new CPACK_WIX_SKIP_PROGRAM_FOLDER
feature) generates GUIDs for most but not all components
when the feature is active.

Generate the remaining GUIDs as well.

Co-Author: Nils Gladitz <nilsglad...@gmail.com>

diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index d7f69a1..85e0ae3 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -35,6 +35,7 @@
 
 cmCPackWIXGenerator::cmCPackWIXGenerator()
   : Patch(0)
+  , ComponentGuidType(cmWIXSourceWriter::WIX_GENERATED_GUID)
 {
 }
 
@@ -234,6 +235,12 @@ bool cmCPackWIXGenerator::InitializeWiXConfiguration()
 }
   }
 
+  // if install folder is supposed to be set absolutely, the default
+  // component guid "*" cannot be used
+  if (cmSystemTools::IsOn(GetOption("CPACK_WIX_SKIP_PROGRAM_FOLDER"))) {
+this->ComponentGuidType = cmWIXSourceWriter::CMAKE_GENERATED_GUID;
+  }
+
   return true;
 }
 
@@ -317,7 +324,9 @@ void cmCPackWIXGenerator::CreateWiXVariablesIncludeFile()
 {
   std::string includeFilename = this->CPackTopLevel + "/cpack_variables.wxi";
 
-  cmWIXSourceWriter includeFile(this->Logger, includeFilename, true);
+  cmWIXSourceWriter includeFile(this->Logger, includeFilename,
+this->ComponentGuidType,
+cmWIXSourceWriter::INCLUDE_ELEMENT_ROOT);
 
   CopyDefinition(includeFile, "CPACK_WIX_PRODUCT_GUID");
   CopyDefinition(includeFile, "CPACK_WIX_UPGRADE_GUID");
@@ -338,7 +347,9 @@ void cmCPackWIXGenerator::CreateWiXPropertiesIncludeFile()
 {
   std::string includeFilename = this->CPackTopLevel + "/properties.wxi";
 
-  cmWIXSourceWriter includeFile(this->Logger, includeFilename, true);
+  cmWIXSourceWriter includeFile(this->Logger, includeFilename,
+this->ComponentGuidType,
+cmWIXSourceWriter::INCLUDE_ELEMENT_ROOT);
 
   std::string prefix = "CPACK_WIX_PROPERTY_";
   std::vector options = GetOptions();
@@ -386,7 +397,9 @@ void 
cmCPackWIXGenerator::CreateWiXProductFragmentIncludeFile()
 {
   std::string includeFilename = this->CPackTopLevel + "/product_fragment.wxi";
 
-  cmWIXSourceWriter includeFile(this->Logger, includeFilename, true);
+  cmWIXSourceWriter includeFile(this->Logger, includeFilename,
+this->ComponentGuidType,
+cmWIXSourceWriter::INCLUDE_ELEMENT_ROOT);
 
   this->Patch->ApplyFragment("#PRODUCT", includeFile);
 }
@@ -413,13 +426,15 @@ void 
cmCPackWIXGenerator::AddDefinition(cmWIXSourceWriter& source,
 
 bool cmCPackWIXGenerator::CreateWiXSourceFiles()
 {
+  // if install folder is supposed to be set absolutely, the default
+  // component guid "*" cannot be used
   std::string directoryDefinitionsFilename =
 this->CPackTopLevel + "/directories.wxs";
 
   this->WixSources.push_back(directoryDefinitionsFilename);
 
   cmWIXDirectoriesSourceWriter directoryDefinitions(
-this->Logger, directoryDefinitionsFilename);
+this->Logger, directoryDefinitionsFilename, this->ComponentGuidType);
   directoryDefinitions.BeginElement("Fragmen

Re: [cmake-developers] PATCH: Bugfix for WIX support

[Nils Gladitz]

On 09/06/2016 03:45 PM, Nils Gladitz wrote:



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



Please verify that I haven't broken anything.


I broke writing of WIX include files. Should be fixed now:
https://cmake.org/gitweb?p=stage/cmake.git;a=commit;h=19f96b8bd54a6dc9c4c08ba90250c3a7ae013227

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: add custom xmlns namespaces into generated .wxs sources

[Nils Gladitz]

On 09/06/2016 03:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote:



Hm, I don't see how I can add a namespace before my patch fragment. If I want to use some 
element from let's say UtilExtension, I need to add the 
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension; attribute in some 
parent XML node as far as I understand (no XML expert though).


You only have to declare the namespace on the element itself. There is 
no need for the parent to have it declared.


So unless you object for other reasons I don't think the patch is necessary?

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: Bugfix for WIX support

[Nils Gladitz]

On 09/06/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


The generated guid values where not set correctly everywhere. This could lead 
to WIX build errors when using the CPACK_WIX_SKIP_PROGRAM_FOLDER option.


Thanks. I modified the patch to work without the global/public 
GenerateComponentGuids and instead pass the state down into each 
individual vmWIXSourceWriter instance:


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

Please verify that I haven't broken anything.

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: add custom xmlns namespaces into generated .wxs sources

[Nils Gladitz]

On 09/06/2016 01:32 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


best regards,
Michael


Can you elaborate your use case for the patch?

I assume this if for custom patch fragments?
In that context wouldn't it suffice to add the namespace declarations to 
the elements that need them (in the patch fragment itself)?


The patch is also missing documentation for the new CPACK_WIX_NAMESPACES 
variable that it introduces.


Thanks.

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] visual studio tries to link to non-existent static version of lib

[Nils Gladitz]

On 23.08.2016 21:36, Jack Stalnaker wrote:

The following works on Linux, for both GNU and Intel compilers:

add_library(mylib SHARED ${mylib_sources})
target_link_libraries(mylib ${mylib_libraries})
...
add_executable(test_mylib test_mylib.c)
target_link_libraries(test_mylib mylib ${test_mylib_libraries})
add_test (TestMylib test_mylib)


However on windows, using Visual Studio, building test_mylib fails 
with the message "cannot open file Debug\mylib.lib".  But I have not 
asked for a static library, and I'm not sure why VS is trying to link 
to it. Is there some extra step I need to take to make this work on 
Windows?


mylib.lib is the import library [1] for your DLL.
The linker is (probably) not creating it because you aren't exporting 
any symbols [2].


Nils

[1] https://en.wikipedia.org/wiki/Dynamic-link_library#Import_libraries
[2] https://msdn.microsoft.com/en-us/library/z4zxe9k8.aspx
--

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

Re: [CMake] Wrong version of cl.exe for x64

[Nils Gladitz]

On 22.08.2016 19:34, Albrecht Schlosser wrote:


So, the conclusion is: since CMake can't figure it out we have to 
_assume_ that the header files can be #included in MSVC projects 
(MinGW works well), hence we should set the corresponding CMake 
variable to true, maybe something like:


if (MSVC)
  set (HAVE_GL_GL_H 1)
endif (MSVC)

Is this what you suggest?


I suppose I'd go with if(WIN32).

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

Re: [CMake] Wrong version of cl.exe for x64

[Nils Gladitz]

On 08/22/2016 01:30 PM, Albrecht Schlosser wrote:


On 22.08.2016 12:54 Nils Gladitz wrote:

On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)


Yes. The Visual Studio generators are meant to work outside of the
visual studio command line environments while the command line
generators (makefiles, ninja) are meant to work from within the visual
studio command line environment.

What that means is that the Visual Studio generators must work 
without it.


Okay, I posted a simple example CMake file to show what happens in my 
case. See new thread:


"Visual Studio generator does not find some header files"

Basically some special (SDK?) header files are not found when 
executing CMake w/o the Visual Studio environment.




E.g. CMake find_path() uses the INCLUDE environment variable (which is 
provided by the visual studio command line environment) if set.


So yes this can influence CMake itself but not Visual Studio.
Since the paths in the INCLUDE environment variable are not used by 
Visual Studio this can result in obvious conflicts.


Since CMake does not (I don't know if it (easily) could) know the 
implicit include directories Visual Studio uses it can not use them in 
find_*() calls either.


In case of the OpenGL library (which on windows is part of the 
windows/platform SDK) cmake e.g. assumes (within the FindOpenGL.cmake 
module) that the header is in an implicit include directory and does not 
try to locate it.


Assuming this matches your use case I would suggest you do the same.

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

Re: [CMake] Wrong version of cl.exe for x64

[Nils Gladitz]

On 08/22/2016 12:18 PM, Albrecht Schlosser wrote:


On 22.08.2016 10:33 Nils Gladitz wrote:


The visual studio command line environments should have no effect when
using the visual studio generators.


Are you sure? Or what does "should" mean here? ;-)


Yes. The Visual Studio generators are meant to work outside of the 
visual studio command line environments while the command line 
generators (makefiles, ninja) are meant to work from within the visual 
studio command line environment.


What that means is that the Visual Studio generators must work without it.

You can of course create manual dependencies from your project e.g. when 
you manually run "cl" from a custom command but such use should 
obviously be avoided since it is non-obvious and there is nothing that 
prevents you from running e.g. the x86 environment while your visual 
studio solution (which will ignore that environment) is targeting amd64.


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

Re: [CMake] Wrong version of cl.exe for x64

[Nils Gladitz]

On 08/22/2016 10:28 AM, J Decker wrote:


Maybe you need a diferent parameter to vcvarsall before running cmake

https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx



The visual studio command line environments should have no effect when 
using the visual studio generators.
They should only be relevant when you use one of the command line 
generators (e.g. makefiles or ninja).


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

Re: [CMake] Wrong version of cl.exe for x64

[Nils Gladitz]

On 08/22/2016 09:27 AM, tonka tonka wrote:


Hey,

I have recently switched to cmake (instead of plain visual studio).
Now i discovered a problem.cmake choose the wrong cl.exe for my x64 
project.




I don't think CMake chooses the compiler when using the visual studio 
generators.
Visual Studio chooses and CMake just records that choice in 
CMAKE__COMPILER.


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

Re: [CMake] Suppressing policy warnings

[Nils Gladitz]

On 08/19/2016 11:18 AM, Robert Bielik wrote:


Hi,

I'm currently using CMake 3.5.0 and I get TONS of CMP0054 policy warnings. So I 
set the policy:

cmake_policy(SET CMP0054 OLD)

in top level CMakeLists.txt file. Nothing happens. I STILL get TONS of warnings.

Help ?


cmake_minimum_required(VERSION) resets all policies to match the given 
version.


So either set the policy after any cmake_minimum_required(VERSION) call,
or don't set this specific policy at all and increase your minimum 
required version to at least 3.1 (will implicitly set the policy to NEW),

or fix (work around) the ambiguities that the policy warnings point to.

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

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

[Nils Gladitz]

On 08/16/2016 11:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:


There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I
think such an interface change would be fine.


Ok I'll do this. Should solve all issues and doubts hopefully.


Great. Thanks.



  Adding FeatureRef to #PRODUCT does not work. I get the following message:

features.wixobj : error LGHT0095 : Multiple primary references were found for 
Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'


Did you try with IgnoreParent="yes" on your FeatureRef element?
It makes sense that there can only be one root-Feature.

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

[Nils Gladitz]

On 08/12/2016 11:50 AM, Stuermer, Michael SP/HZA-ZSEP wrote:




Patch 5 seems to implement patching of FeatureRef rather than the original
Feature elements.
I am not sure if this is what you intended but this could be error prone given
that there could in theory be any number (0-n) FeatureRef elements for any
corresponding Feature element.

Nils

The intention was to be able to add custom components that are added as extra 
.wxs source files to certain features. If there are more convenient ways to do 
this I will be happy to change the implementation or adapt my WIX project. But 
so far this seemed to be a very easy and intuitive solution: the additional 
component references are added in the same place where all other component 
references are added as well.


I understand the general intention but not why you elected to patch 
FeatureRef elements instead of the Feature elements themselves.


This would not be any more convenient but would certainly match 
expectations and be less ill defined.
e.g. when I specify a patch for a Feature I expect that the Feature with 
the given ID gets patched.


Arguments against patching a FeatureRef instead are:
- There can be n FeatureRef elements for any Feature element in which 
case it would not be obvious if the patch should be applied to one 
(which?) or all of these

- While similar FeatureRef and Feature don't take the same Child elements
- You can already define your own FeatureRef elements (referencing any 
of the pre-existing Feature elements if wanted) without having to use 
the patch mechanism


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

[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 5 seems to implement patching of FeatureRef rather than the 
original Feature elements.
I am not sure if this is what you intended but this could be error prone 
given that there could in theory be any number (0-n) FeatureRef elements 
for any corresponding Feature element.


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

[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


I fixed a minor whitespace error (did you forget 
|./Utilities/SetupForDevelopment.sh ?), added a release note, extended 
the documentation, reworded the commit message and merged to "next" for 
testing.


The feature itself seems to work as advertised though I am not too fond 
of the semantics which is why my contribution to the documentation is 
primarily a cautionary note.


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-commits] CMake branch, next, updated. v3.6.1-1137-g25bd0c3

[Nils Gladitz]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  25bd0c3824b55ba10c23bc837ca28879487686bc (commit)
   via  17bbf6af1ecca15194a693d31fdd8163aacfd994 (commit)
   via  5a62e0c1721281503c8b4cd9d4d3d0de8abebf0f (commit)
  from  8c38d8ed5f41f8b57e94b1e9dff923462f992d87 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=25bd0c3824b55ba10c23bc837ca28879487686bc
commit 25bd0c3824b55ba10c23bc837ca28879487686bc
Merge: 8c38d8e 17bbf6a
Author: Nils Gladitz <nilsglad...@gmail.com>
AuthorDate: Mon Aug 8 08:46:35 2016 -0400
Commit: CMake Topic Stage <kwro...@kitware.com>
CommitDate: Mon Aug 8 08:46:35 2016 -0400

Merge topic 'wix-custom-install-dir' into next

17bbf6af CPackWIX: Implement new CPACK_WIX_SKIP_PROGRAM_FOLDER feature
5a62e0c1 CMake Nightly Date Stamp


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=17bbf6af1ecca15194a693d31fdd8163aacfd994
commit 17bbf6af1ecca15194a693d31fdd8163aacfd994
Author: Michael Stürmer <michael.stuer...@schaeffler.com>
AuthorDate: Wed Jul 20 15:32:38 2016 +0200
Commit: Nils Gladitz <nilsglad...@gmail.com>
CommitDate: Mon Aug 8 13:42:23 2016 +0200

CPackWIX: Implement new CPACK_WIX_SKIP_PROGRAM_FOLDER feature

The new variable allows setting of a custom absolute installation prefix
outside of the ProgramFiles folders.

diff --git a/Help/release/dev/wix-custom-install-dir.rst 
b/Help/release/dev/wix-custom-install-dir.rst
new file mode 100644
index 000..cd12a88
--- /dev/null
+++ b/Help/release/dev/wix-custom-install-dir.rst
@@ -0,0 +1,7 @@
+wix-custom-install-dir
+--
+
+* The CPack WIX generator now supports
+  :variable:`CPACK_WIX_SKIP_PROGRAM_FOLDER` to allow specification
+  of a custom absolute installation prefix outside
+  of the ProgramFiles folders.
diff --git a/Modules/CPackWIX.cmake b/Modules/CPackWIX.cmake
index 10926c0..08ff0cb 100644
--- a/Modules/CPackWIX.cmake
+++ b/Modules/CPackWIX.cmake
@@ -248,6 +248,23 @@
 # Sets the description of the root install feature in the WIX installer. Same 
as
 # CPACK_COMPONENT__DESCRIPTION for components.
 #
+# .. variable:: CPACK_WIX_SKIP_PROGRAM_FOLDER
+#
+# If this variable is set to true, the default install location
+# of the generated package will be CPACK_PACKAGE_INSTALL_DIRECTORY directly.
+# The install location will not be located relatively below
+# ProgramFiles or ProgramFiles64.
+#
+#   .. note::
+# Installers created with this feature do not take differences
+# between the system on which the installer is created
+# and the system on which the installer might be used into account.
+#
+# It is therefor possible that the installer e.g. might try to install
+# onto a drive that is unavailable or unintended or a path that does not
+# follow the localization or convention of the system on which the
+# installation is performed.
+#
 
 #=
 # Copyright 2014-2015 Kitware, Inc.
diff --git a/Source/CPack/WiX/cmCPackWIXGenerator.cxx 
b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
index 3ecc14d..d7f69a1 100644
--- a/Source/CPack/WiX/cmCPackWIXGenerator.cxx
+++ b/Source/CPack/WiX/cmCPackWIXGenerator.cxx
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cmWIXDirectoriesSourceWriter.h"
 #include "cmWIXFeaturesSourceWriter.h"
@@ -441,6 +442,11 @@ bool cmCPackWIXGenerator::CreateWiXSourceFiles()
   cmWIXFilesSourceWriter fileDefinitions(this->Logger,
  fileDefinitionsFilename);
 
+  // if install folder is supposed to be set absolutely, the default
+  // component guid "*" cannot be used
+  fileDefinitions.GenerateComponentGuids =
+cmSystemTools::IsOn(GetOption("CPACK_WIX_SKIP_PROGRAM_FOLDER"));
+
   fileDefinitions.BeginElement("Fragment");
 
   std::string featureDefinitionsFilename =
@@ -566,6 +572,9 @@ bool cmCPackWIXGenerator::CreateWiXSourceFiles()
 
 std::string cmCPackWIXGenerator::GetProgramFilesFolderId() const
 {
+  if (cmSystemTools::IsOn(GetOption("CPACK_WIX_SKIP_PROGRAM_FOLDER"))) {
+return "";
+  }
   if (GetArchitecture() == "x86") {
 return "ProgramFilesFolder";
   } else {
diff --git a/Source/CPack/WiX/cmWIXDirectoriesSourceWriter.cxx 
b/Source/CPack/WiX/cmWIXDirectoriesSourceWriter.cxx
index de64059..97e3a51 100644
--- a/Source/CPack/WiX/cmWIXDirectoriesSourceWriter.cxx
+++ b/Source/CPack/WiX/cmWIXDirectoriesSourceWriter.cxx
@@ -52,8 +52,1

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

[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