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

[Nils Gladitz]

On Mon, Apr 8, 2019 at 2:07 AM Cook, Steven (G&I) 
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&I) 
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

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] 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] ; list

[Nils Gladitz]

On Thu, Sep 21, 2017 at 3:26 PM, Patrick Welche  wrote:

> Having run cmake 3.9.2 once already, I see:
>
> $ cat CMakeLists.txt
> set(var one two)
> message(${var})
> $ cmake .
> onetwo
> -- Configuring done
> -- Generating done
> -- Build files have been written to: /tmp/cmaketest
>
> Would you have expected "one;two" rather than "onetwo"?
>

When unquoted each list items is turned into a distinct argument for the
message() invocation.
message() concatenates its arguments hence "onetwo".

To preserve the semicolon in the message try message("${var}")

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] rebuild externalprojects

[Nils Gladitz]

On Thu, Sep 21, 2017 at 1:09 PM, J Decker  wrote:

> how do I make sure that externalprojects get built if I change a source in
> one?
>

"BUILD_ALWAYS 1" should always trigger the build of the external project.
This would be required since only the external project's build system will
know if something relevant has changed or not.

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

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



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

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] [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] 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] problem creating cmake for ns3 library

[Nils Gladitz]

On 31.07.2016 09:19, Kapil Gupta wrote:


-- Looking for lib ns3-core
-- Looking for lib ns3-core - not found



There might be more issues but to start with:
In 
https://github.com/kneelb4darth/qosManet/blob/master/cmake/FindNS3.cmake#L23

NAME should be NAMES.

Same here:
https://github.com/kneelb4darth/qosManet/blob/master/cmake/FindNS3.cmake#L30

Beyond that the module seems to break a few conventions (e.g. using 
plural names for cache variables or automatic extension of include and 
link directories); you might want to take a look at:

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

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] Policy CMP0063 is not set: Honor visibility properties for all target

[Nils Gladitz]

On 18.06.2016 13:28, Alexander Shukaev wrote:


But they in fact do.  How come?


I am not sure what facts you mean ... they don't:

   cmake_policy(SET CMP0063 NEW)
   cmake_policy(GET CMP0063 POLICY_VALUE_BEFORE)
   cmake_minimum_required(VERSION 3.1.0)
   cmake_policy(GET CMP0063 POLICY_VALUE_AFTER)

   message("[${POLICY_VALUE_BEFORE}] [${POLICY_VALUE_AFTER}]")

   file(WRITE foo.cpp "int main() {}")

   set(CMAKE_CXX_VISIBILITY_PRESET hidden)

   add_executable(foo foo.cpp)


Expectedly outputs for me:
[NEW] []

(plus the policy warning since CMP0063 is in fact not set)

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] Policy CMP0063 is not set: Honor visibility properties for all target

[Nils Gladitz]

On 18.06.2016 13:03, Alexander Shukaev wrote:


if(POLICY CMP0011)
  cmake_policy(SET CMP0011 NEW)
endif()
if(POLICY CMP0063)
  cmake_policy(SET CMP0063 NEW)
endif()

CMakeLists.txt:

include(xxx)
cmake_minimum_required(VERSION 3.1.0)

and it still works.  Is it because the version is high enough so it 
does not reset policies?


The cmake_minimum_required() call will set CMP0011 to NEW and will unset 
CMP0063.
This is because CMP0011 was introduced before CMake 3.1.0 (the version 
you require) and CMP0063 was introduced afterwards (in CMake 3.3).


Given your sequence of calls none of the previous cmake_policy(SET) 
calls will have any effect.


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] Policy CMP0063 is not set: Honor visibility properties for all target

[Nils Gladitz]

On 18.06.2016 11:38, Alexander Shukaev wrote:


I did try both variants, after and before

cmake_minimum_required(VERSION)

but the result is the same.  The scope is for sure parent to targets.


I don't know what else it could be but this works fine for me:

   cmake_minimum_required(VERSION 2.8.12)

   if(POLICY CMP0063)
cmake_policy(SET CMP0063 NEW)
   endif()

   file(WRITE foo.cpp "int main() {}")

   set(CMAKE_CXX_VISIBILITY_PRESET hidden)

   add_executable(foo foo.cpp)


Is it possible that the scope where the policy warning comes from has 
its own cmake_minimum_required(VERSION) call? (e.g. is there more than one?)


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] Policy CMP0063 is not set: Honor visibility properties for all target

[Nils Gladitz]

On 18.06.2016 09:34, Alexander Shukaev wrote:

Hello,

CMake 3.5.2 here.  Why explicitly setting the CMP0063 policy to NEW 
does not suppress the warning and actually use that new policy?  That is


if(POLICY CMP0063)
  cmake_policy(SET CMP0063 NEW)
endif()

and I still get

  Policy CMP0063 is not set: Honor visibility properties for all target
  types.  Run "cmake --help-policy CMP0063" for policy details. Use the
  cmake_policy command to set the policy and suppress this warning.


Did you call cmake_minimum_required(VERSION) after setting that policy?
That would reset all policies based on the requested version.

Otherwise did you set the policy before creating your targets and in a 
scope that is parent to all targets involved?


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] Finding 32bit libs on 64bit Ubuntu install

[Nils Gladitz]

On 22.04.2016 20:59, Nick Deubert wrote:

Hey everyone, I am trying to build and link some 32bit binaries on
Ubuntu 15.10 64bit, but no matter what combination of arguments I give
FIND_LIBRARY I cannot get it to use the 32bit libs. I have been
scouring the mailing lists and came up with all these things to try
but nothing has worked so far. I am using cmake 3.0.2. Please let me
know what I am missing. Thanks in advance for your help.
Nick


Run cmake e.g. like this:
CC="gcc -m32" CXX="g++ -m32" cmake ..

Don't try to add -m32 within the project.
This way the try_compile() tests that cmake runs will correctly 
determine that you are building 32-bit and find_library() will use the 
correct paths.


Make sure you start with a fresh 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Version compatibility?

[Nils Gladitz]

On 04/25/2016 02:29 PM, Craig Scott wrote:
I personally have found myself having to look up to his sort of 
version info a lot lately. It sounds like others do too. Perhaps a 
more sustainable approach would be to include the version details in 
the CMAKE docs themselves. For each command, module, variable, etc. 
it's documentation could state the version it was added. Some may 
warrant further info for version(s) where significant changes were 
made (eg keywords added to a command). Realistically, it would have to 
be done progressively and obviously with agreement from the Kitware 
side. It would only work if it became part of the change process 
whereby any new features or changes must include such version details. 
It would be interesting to hear what Kitware think of the idea. Any 
chance?


I've also made use of such information from time to time but I think it 
has been the exception and it doesn't normally come up during my regular 
development workflow.


I assume for most projects there is a single 
cmake_minimum_required(VERSION).
Which means to see what is and what isn't available I only have to check 
that specific version's documentation.


I am curious as to what kind of use case results in having to require 
cross-version information as provided by the compatibility matrix "a lot".


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] Finding all the libraries except for one located in the last path dir

[Nils Gladitz]

On 05.04.2016 23:31, Salazar De Troya, Miguel wrote:



with no line break, whereas the output variable lib_dirs:

message(${lib_dirs})


/usr/lib/lib/usr/lib64/usr/local/tools/vtk-6.1.0/lib/g/g92/miguel/petsc-3.6.2/miguel-opt/lib/usr/local/tools/openmpi-intel-1.8.4/lib/usr/local/tools/ic-14.0.174/composer_xe_2013_sp1.3.174/compiler/lib/intel64/usr/lib/gcc/x86_64-redhat-linux/4.4.7/g/g92/miguel/code/libmesh_2D/lib


does have a line break and also the semicolons are removed. What’s 
happening here and how can I get rid of that?




message() concatenates its (semicolon separated) arguments.

try:
message("${lib_dirs}")

Note the quotes.

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] VERSION and SOVERSION in a module

[Nils Gladitz]

On 04/04/2016 10:33 AM, Kristian wrote:

Hey,

I have a question. I have a project, which is compiled on two
different build machines with ninja (trunk and branch). The
CMakeLists.txt is the same when it comes to a part, where the VERSION
and SOVERSION part is set through the function
'set_target_properties'.

But on the first build machines, setting the VERSION and SOVERSION
works, on the other machine it does not work. On the second machine
(where the build fails), I recently upgraded CMake to 3.5 (I compiled
and installed it on my own). The first build machine has CMake with
version 2.8.11 (installed from local package manager yum).

I've tried some things till I got a minimum example, where I could
reproduce the error. The problem is calling add_library with MODULE.



This behavior was deliberately changed by:
https://cmake.org/gitweb?p=cmake.git;a=commit;h=f799ffb5cb895855ac2aba54765622b81db5be38

Which is in CMake since ~3.4.0.

The change is related to this issue:
https://cmake.org/Bug/view.php?id=15705

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] Debian SID / CMake 3.5.0-1 / FindBoost / CTest

[Nils Gladitz]

On 03/29/2016 10:31 AM, Vincent Huber wrote:


Hello everyone,

In a |CTest| process, I have to determine the |Boost_VERSION|.
To do so, I just add |FIND_PACKAGE(Boost)| to my configuration file.
I didn’t had any problems since a |cmake| update on Debian/SID to 
cmake 3.5.0.


From now, I have:
|-- Looking for boost CMake Error at 
/usr/share/cmake-3.5/Modules/FindBoost.cmake:896 (add_library): 
Unknown CMake command "add_library". Call Stack (most recent call 
first): /home/vhuber/feelpp/cmake/dashboard/testsuite.cmake:328 
(FIND_PACKAGE)|​


​If I run a standard |cmake| process with a |FIND_PACKAGE(Boost)| 
everything goes well.


I do not clearly understand what is going on.



add_library() is used by an increasing number of find modules to define 
IMPORTED targets.
IMPORTED targets are the preferred and most convenient way to use 
libraries located by find modules.


Since add_library() is only meaningful in build system definitions it is 
not available to ctest.



​I do not have theses problems with cmake 3.4.3

What can I do to solve that problem ?



You haven't mentioned why you need to determine the Boost version in 
your ctest script but if you do still require it I would implement 
custom logic (you could base it on the existing logic in FindBoost.cmake).


Using library find modules from any context other than cmake project 
files is ill defined even before the changes that introduced imported 
targets.
The boost find module specifically uses compiler and platform 
information that is not available in ctest scripts (e.g. boost library 
file names can be mangled differently depending on which 
compilers/versions are used and can be located differently depending on 
bitness).


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] execute_process seems to execute in parallel and also only shows output of last command

[Nils Gladitz]

On 03/24/2016 12:58 PM, xyzdra...@fastmail.fm wrote:

The CMake 3.5.0 documentation specifies the execute_process command like
this:

 execute_process(COMMAND  [args1...]]
 [COMMAND  [args2...] [...]]
 [WORKING_DIRECTORY ]
 [...] )

This mail here clarifies that all commands should be run sequentially:
https://cmake.org/pipermail/cmake/2009-June/030158.html


TLDR; what that mail states is that add_custom_command/add_custom_target 
COMMANDs run in sequence.

You use neither of those.

As stated by the quote  from the execute_process() documentation it runs 
the commands in parallel by design so that each process's output can be 
fed to the next process's 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] [cmake-developers] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Nils Gladitz]

On 03/04/2016 12:42 PM, Dan Liew wrote:

Thanks for this. Shouldn't the fact that ``LINK_FLAGS`` is a string
property and not a list property be in the ``cmake-properties``
documentation? The version of the documentation for my version of
CMake (3.4.3) doesn't say what the property type is.


Perhaps though the plain string properties predate the list properties 
which is probably why the documentation does it the other way around e.g.
https://cmake.org/cmake/help/v3.4/prop_dir/COMPILE_OPTIONS.html is 
documented explicitly as a list property.


COMPILE_OPTIONS deprecated the old COMPILE_FLAGS property (which was 
plain string based).
For LINK_FLAGS the same thing was supposed to happen at some point but 
the topic working on this seems to have stalled.


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-developers] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Nils Gladitz]

On 03.03.2016 22:57, Dan Liew wrote:

Hi,

I noticed recently is you do something like this

add_executable(foo a.cpp b.cpp)
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-fopenmp")
set_property(TARGET shell APPEND PROPERTY LINK_FLAGS "-static")

then the flags that end up being passed to the compiler during linking
are like this.

gcc -g -O0 -fopenmp;-static

It looks like when using the property with APPEND it becomes a list
but when emitted the list isn't expanded properly. I noticed this
using CMake 3.4.3 using the "Unix Makefile" generator.

Is this intentional or is this a bug?


LINK_FLAGS is not a list property; flags have to be whitespace separated.
You can use APPEND_STRING instead of APPEND for this.

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] Good practice: using INTERFACE-libraries in FindABC.cmake?

[Nils Gladitz]

On 02/29/2016 04:06 PM, Clément Gregoire wrote:


Speaking of imported targets, I'm wondering why alias imported targets 
aren't added to all default FindXXX.cmake scripts. This would help 
provide better examples, and have the community use better 
cmakelists.txt and hopefully reduce the bad usages of 
include_directories and such




I assume you don't mean alias as in "ALIAS" targets ...

Many of the Find*.cmake modules included with CMake do provide imported 
targets now.

e.g. according to grep:
FindIce.cmake
FindPNG.cmake
FindGLUT.cmake
FindXalanC.cmake
FindOpenSSL.cmake
FindThreads.cmake
FindQt4.cmake
FindXercesC.cmake
FindTIFF.cmake
FindGTK2.cmake
FindZLIB.cmake
FindGTest.cmake
FindGSL.cmake
FindBoost.cmake
FindGLEW.cmake

For the rest there probably is just a lack of maintainers ... patches 
are probably welcome.


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] Good practice: using INTERFACE-libraries in FindABC.cmake?

[Nils Gladitz]

On 02/29/2016 03:34 PM, Patrick Boettcher wrote:

Hi list,

I came across the INTERFACE-type of libraries when writing a
FindModule.cmake-file for custom libraries installed by my
project.

Here is what I'm doing after having found the libraries and the
determined the paths: LIB1 is the library and LIB1_INCLUDE_DIRS its
include-dirs:

   add_library(name INTERFACE)

   target_link_libraries(name INTERFACE ${LIB1})

   if(FFTW3_FOUND)
target_include_directories(name INTERFACE
{$FFTW3_INCLUDE_DIRS})
target_link_libraries(name INTERFACE ${FFTW3_LIBRARIES} )
   endif()

   target_include_directories(name INTERFACE ${LIB1_INCLUDE_DIRS})

   # need c++11 compile options for if-name
   set_property(TARGET name PROPERTY
INTERFACE_COMPILE_FEATURES cxx_range_for)

This makes that in the CMakeLists.txt which includes my package-file a
user needing libname for his executable does:

   add_executable(main main.cpp)
   target_link_libraries(main name)

This will

1) set C++11 flags for compilation
2) set the right include-pathes
3) link with the right libraries as per my order

Awesome. But is this a good practice? Are there any pitfalls?


This sounds like a use case for IMPORTED rather than INTERFACE libraries.
INTERFACE libraries can be IMPORTED as well but are not intended for 
pre-build linkable libraries (which you seem to have).


This documents how to create find modules with IMPORTED targets:
https://cmake.org/cmake/help/v3.4/manual/cmake-developer.7.html#find-modules

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] A function and its arguments

[Nils Gladitz]

On 28.02.2016 21:57, Kristian wrote:

[...]


test_me(1 2 3)


Then I get this output:


test_me
  -> 1
  -> 2
  -> Number of arguments: 3
  -> All arguments: 123
  -> 0. argument: 1
  -> 1. argument: 2
  -> 2. argument: 3
  -> Unexpected arguments: 3



I would expect, that the line "All arguments" would look like "All
arguments: 1 2 3", and not "All arguments: 123".

What is the thought behind this behaviour?


This is due to how you call message() which concatenates its arguments.

Instead try e.g.
message(" -> All arguments: ${ARGV}")

Which should output " -> All arguments: 1;2;3" (CMake's internal list 
separator is semicolon).


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] globs case sensitivity depends on platform

[Nils Gladitz]

On 01/28/2016 12:56 PM, 🐋 Jan Hegewald wrote:

Hi all,
I have some trouble with file globbing using the glob command like so:
file(GLOB all_sources ${src_home}/*.F**)


You might already be aware but CMake discourages using GLOB for source 
files; though for different reasons (see Note in [1]).
Incidentally using explicit source file listings would work around this 
issue as well.


Nils

[1] https://cmake.org/cmake/help/v3.4/command/file.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] Multiple Visual Studio Solutions through same master CMakeLists.txt

[Nils Gladitz]

On 01/28/2016 12:42 PM, Nikita Barawade wrote:




Hi All ,

It is possible to same master CMakeList to generate multiple visual 
studio solution files ?


here is my master CMakeList :

cmake_minimum_required (VERSION 2.8.11)
project (Myproject_all)

set_property (GLOBAL PROPERTY USE_FOLDERS ON)

# Set compiler flags and options.
# enable the Visual Studio warning level to 4
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")

# Sub-directories where more CMakeLists.txt exist
add_subdirectory (lib1)
add_subdirectory (TestApp1)
add_subdirectory (lib2)
add_subdirectory (TestApp2)
add_subdirectory (TestApp3)

Now , my project "Myproject_all" includes all sub-projects as 
lib1,TestApp1,lib2,TestApp2,TestApp3 (testApps depend on libraries )
I want another solution to be generated through same CMakeList for 
example with name "Myproject" which includes only ,

lib1,TestApp1,lib2.
I should not always edit master CMakeList to change project name and 
remove TestApp2 and TestApp3.Is there any way to automate this?


CMake generates one solution per directory (CMakeLists.txt) that has its 
own project() call.
To put lib1,TestApp1,lib2 into their own solution you would therefor 
have to put them into a common parent directory (distinct from the other 
targets) and give that parent directory's CMakeLists.txt its own 
project(Myproject) call.


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] Importing a static library, then adding dependencies. Should the dependencies be transitive? They aren't for me!

[Nils Gladitz]

On 26.01.2016 21:25, Johnson, Matt (GE Healthcare) wrote:

I'm using the Visual Studio 2013 generator and cmake 3.4.3.
Example:
add_library(NS::a_lib STATIC IMPORTED)
set_target_properties(NS::a_lib PROPERTIES IMPORTED_LOCATION ${a_lib_location})
set_target_properties(NS::a_lib PROPERTIES INTERFACE_LINK_LIBRARIES 
"/path/to/a/another_lib.lib")
set_target_properties(NS::a_lib PROPERTIES INTERFACE_INCLUDE_DIRECTORIES 
"an/include/dir")

add_library(NS::b_lib STATIC IMPORTED)
set_target_properties(NS::b_lib PROPERTIES IMPORTED_LOCATION ${b_lib_location})
add_dependencies(NS::b_lib NS::a_lib)

add_executable(test_exe main.cpp)
target_link_libraries(test_exe NS::b_lib) #I expect to pull in all of A's stuff 
too.  Howver, it doesn't for me.

Assume I have two libraries, A and B.  A has some libraries that it links to.  B 
depends on A.  I add import targets for both A and B.  I use add_dependencies to 
signal the B->A dependency.  When I use target_link_libraries for an executable 
and only list B, should it auto pull in A and A's dependencies?  For me, all I get 
is B.  I don't get any of its dependencies.  Nor do I get A's include directories. 
 Am I doing something wrong or misunderstanding the usage of these functions?

I've done a lot of googling and searching the mailing list.  I do see a couple 
of bugs that revolved around this, but all of them seem to indicate that they 
are fixed and this is supported.  Am I wrong?  Do I have to manually set the 
INTERFACE_LINK_LIBRARIES of B?


Yes you have to set INTERFACE_LINK_LIBRARIES.
add_dependencies() is for order (not link) dependencies.

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

[Nils Gladitz]

On 01/26/2016 06:35 AM, 陆秋文 wrote:
I have the need to link a shared library to all the targets without 
modifying the CMakeLists.txt(for example, tcmalloc.so). I used the 
command:


# cmake -DCMAKE_C_IMPLICIT_LINK_LIBRARIES:STRING=tcmalloc

However, It didn't work. I used the message() command to print the 
CMAKE_C_IMPLICIT_LINK_LIBRARIES, It show:


-- CMAKE_C_IMPLICIT_LINK_LIBRARIES=c

Can someone point me why this happens? Thanks very much!


Implicit link libraries are those that the compiler (not CMake) itself 
implicitly links.
They are detected by CMake and stored in the variable; the variable is 
not meant to be modified.


I can't think of any way to portably link libraries without modifying 
the project.
(There are linker flag variables e.g. CMAKE_EXE_LINKER_FLAGS but they 
are inserted before object files on the command line which will not work 
for many toolsets)


link_libraries() [1] might have the smallest impact if you do end up 
having to modify the project.


Nils

[1] https://cmake.org/cmake/help/v3.4/command/link_libraries.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] Code::blocks: parallel build from IDE

[Nils Gladitz]

On 17.01.2016 12:45, Dimitri Kaparis wrote:
On Sat, Jan 9, 2016 at 9:16 PM, Alexander Neundorf 
mailto:a.neundorf-w...@gmx.net>> wrote:



Oops, sorry, that's not implemented for C::B.

Alex


Any plans on it, or an idea for a workaround?


As a workaround perhaps "CodeBlocks - Ninja" would be an option?
ninja builds parallel 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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Why does INTERFACE type targets only support whitelisted properties?

[Nils Gladitz]

On 01/08/2016 02:50 PM, Yves Frederix wrote:

You are explicitly mentioning 'setting' of a property. IMHO there is a
big difference between setting and getting a property. If
white/blacklisting is enforced during setting only, wouldn't this be
sufficient? This would make it possible to simply access all
properties that are automatically assigned to the target (which I
assume implies that by definition they should make sense?). A
non-acceptable property could not have been set and would hence not be
found, making it possible to check for its existence in the "standard"
way.


The same argument might hold for getting of properties.
E.g. hypothetically if SOURCE_DIR were not set for INTERFACE properties 
now but was implemented in the future.



A user might e.g. think that a specific property should work because CMake
did not issue any diagnostics and open an issue.
The diagnostic implies that this behavior is by design.

It also prevents users from using existing properties which currently don't
have semantics for INTERFACE targets but might be implemented in the future
(potentially with different semantics than expected by the user).

Ok, this somehow contradicts my above assumption and is somewhat
surprising. Wouldn't it make sense to simply not set these properties
in the first place if they have incorrect semantics? This way,
get_property would not need to care about them and it would anyhow not
stop their correct implementation in the future.


I meant existing as in defined for regular build targets not as in 
actually set for interface targets.
get_property() would return an empty string for those if they weren't 
whitelisted and one might argue that this could suffice.
On the other hand users often assume that they get a valid value and 
don't actually check.




I think allowing custom (non cmake defined) properties might be a valid
argument.
These could perhaps also be supported through e.g. user extension of the
whitelist.

I like this idea. With this in place, one would not need to wait for a
new CMake release if a valid property were missing from the whitelist
or if one wanted to use custom properties.


I don't think anything should be changed however unless there are actual use
cases that aren't supported by the current implementation.

Does this mean that you would have doubts about patches that:
  - provide a way for the user to extend the whitelist?
  - remove the need for whitelisting in get_property by making CMake
only automatically assign sensible target properties?


The issue is less that CMake assigns these properties (I don't know of 
any such case but I haven't checked) and more that users might just 
expect them to be set (which does not provide a diagnostic).


Personally I would not object to either approach as long as there are 
actual use cases.

Without use cases such changes would be by definition useless.

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] Why does INTERFACE type targets only support whitelisted properties?

[Nils Gladitz]

On 01/08/2016 01:07 PM, Yves Frederix wrote:

It might help the discussion if you could elaborate what use cases you have
in mind for non-whitelisted properties.

I deliberately did not mention my particular use case from the start
simply because I am interested in the reasoning behind the limitation,
not directly in how I can work around a particular instance ;)
However, since you asked, in this case I was trying to access the
SOURCE_DIR property of an INTERFACE target. This property is in fact
defined on the target, but I cannot access it due to the whitelisting
being enforced by get_property.


Still at the very least this might be an argument to whitelist SOURCE_DIR.

An argument for the whitelist diagnostics might be that it reduces 
reports from users which try to set build properties that do not have 
any effect in context of interface targets.
A user might e.g. think that a specific property should work because 
CMake did not issue any diagnostics and open an issue.

The diagnostic implies that this behavior is by design.

It also prevents users from using existing properties which currently 
don't have semantics for INTERFACE targets but might be implemented in 
the future (potentially with different semantics than expected by the user).





Assuming you mean the recent discussion on the FOLDER property:
   The FOLDER property would have no effect on interface targets even if the
property were whitelisted.
   Interface targets don't have project files so there is nothing to be
sorted into a folder either.

This was indeed the discussion I was referring to. One could discuss
whether or not interface targets should have project files and/or
source files associated to them (as one would expect of a header-only
library), but I am trying not to go there at this point. Being able to
get/set any property without CMake exiting with an error could be seen
independent of this I think.


I would also see this as an independent issue.
If there were projects and sources for interface targets that would be 
an argument to whitelist e.g. FOLDER not an argument to allow all 
properties.





As for whitelisting vs blacklisting:
   The whitelist is significantly shorter and easier to maintain (when new
properties are added) than an equivalent blacklist.

I cannot really judge this statement (what properties should really
need to be blacklisted? All standard CMake target properties?)


To start with all CMake target properties that aren't currently on the 
whitelist.




In any case, if blacklisting were used, it would allow a developer to
assign custom target properties (for the sake of argument, let's
assume that in some more complex projects one could make good use of
them) without having to give this custom property a name that starts
with INTERFACE_.


I think allowing custom (non cmake defined) properties might be a valid 
argument.
These could perhaps also be supported through e.g. user extension of the 
whitelist.


I don't think anything should be changed however unless there are actual 
use cases that aren't supported by the current implementation.


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] Why does INTERFACE type targets only support whitelisted properties?

[Nils Gladitz]

On 01/08/2016 11:22 AM, Yves Frederix wrote:

Hi all,

Motivated by my own struggles with targets of type INTERFACE and a
recent post on this list, I was wondering what is the rationale behind
allowing only a whitelisted set of properties on targets of this type.
I understand that one of the use cases for INTERFACE libraries is to
have a way to work with header-only libraries in a more or less
standard way. Yes, the current implementation is far from optimal on
more than one aspect, but I never understood the reason for the
whitelisting (also google didn't make me any wiser). What am I
missing? Wouldn't INTERFACE targets be easier to use without these
restrictions (or alternatively by switching to blacklisting of some
properties to protect a user from having wrong expectations)?


It might help the discussion if you could elaborate what use cases you 
have in mind for non-whitelisted properties.


Assuming you mean the recent discussion on the FOLDER property:
  The FOLDER property would have no effect on interface targets even if 
the property were whitelisted.
  Interface targets don't have project files so there is nothing to be 
sorted into a folder either.


As for whitelisting vs blacklisting:
  The whitelist is significantly shorter and easier to maintain (when 
new properties are added) than an equivalent blacklist.


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] Cannot set FOLDER property to an interface (header-only) target

[Nils Gladitz]

On 31.12.2015 14:19, David Cole via CMake wrote:
I can't think of a reason why we would not whitelist the FOLDER 
property... Unless somebody else chimes in with one, perhaps you could 
submit a proposed patch to whitelist it?


As far as I remember INTERFACE libraries don't generate visual studio 
projects.
Without generated projects there is nothing to be organized by the 
FOLDER property.


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 current visualstudio version?

[Nils Gladitz]

On 28.12.2015 06:50, Xi Shen wrote:
Strange, the FindBoost module expects boost libraries start with 
"boost_" by default. But the libraries I got from the default build 
configuration start with "libboost_". No wonder it did not work the 
first I tried.


This somewhat depends on platform but as far as I remember e.g. on 
Windows the Boost static libraries begin with "lib".

While the import libraries for the DLL version of the library do not.

To locate the static libraries you would e.g. set(Boost_USE_STATIC_LIBS 
ON) before calling find_package() for Boost.


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