Re: [CMake] Support of compile features for Fujitsu C++ Compiler

[Kai Wolf]

If you want to add support to your specific compiler, you could add or extend 
another Fujitsu-DetermineCompiler.cmake
file and append your CMAKE_MODULE_PATH in order to CMake to find it. You 
probably also need to adjust
*Fujitsu-CXX.cmake, Fujitsu-CXX-FeatureTests.cmake and so on.

I gave a talk a few years ago that shortly explains the whole process of CMake 
initialization and compiler verification which
you can find here: 
https://github.com/NewProggie/Talks/blob/master/2017-06-dep-management-with-cmake-MUC%2B%2B.pdf
 



Greetings,

Kai

http://kai-wolf.me
http://effective-cmake.com

> Am 26.04.2019 um 07:35 schrieb Zehner　Paul :
> 
> Hello Cmake community,
> 
> I would like to use Cmake to build research simulation programs in a Fujitsu 
> supercomputer environment. Unfortunately, it seems that Cmake (version 3.14) 
> does not support any compile feature for the Fujitsu C++ compiler (FCCpx, 
> version 2.0.0 P-id: T01815-02 (Jul 12 2018 13:13:18)). I add I am pretty new 
> to Cmake. Searching for similar issues, I found only this 
> [thread](https://cmake.org/pipermail/cmake-developers/2014-August/010989.html 
> ), 
> which talk about basic support of the compiler.
> 
> I tested it on a simple project, and the line:
> 
> ```cmake
> target_compile_features(test PUBLIC cxx_std_11)
> ```
> 
> fails with this message:
> 
> ```
> CMake Error at CMakeLists.txt:15 (target_compile_features):
>   target_compile_features no known features for CXX compiler
> 
>   "Fujitsu"
> 
>   version .
> 
> ```
> 
> So, it seems that the compiler is detected (without its version), but compile 
> features are not known. To be sure, I ran this simple test to list any 
> supported features:
> 
> ```cmake
> cmake_minimum_required(VERSION 3.1.0 FATAL_ERROR)
> project(foobar CXX)
> message("Your C++ compiler supports these C++ features:")
> foreach(i ${CMAKE_CXX_COMPILE_FEATURES})
> message("${i}")
> endforeach()
> ```
> 
> and no feature are listed.
> 
> So, what should I do from now on? Are there some people here using Cmake with 
> Fujitsu who could help me? Should I propose a patch with the different 
> compile features of the compiler? Or should I address it to Fujitsu?
> 
> Thanks for your help,
> 
> --
> Paul Zehner, Ph. D.
> Invited Researcher
> Numerical Simulation Research Unit
> Japan Aerospace Exploration Agency
> 7-44-1 Jindaiji Higashi-machi, Chofu-shi, Tokyo
> 182-8522, Japan
> Tel. +81-50-3362-7933
> Fax. +81-422-40-3327
> zehner.p...@jaxa.jp 
> www.jaxa.jp 
> --
> 
> Powered by www.kitware.com 
> 
> Please keep messages on-topic and check the CMake FAQ 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 
> 


signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Kai Wolf]

Well, as of right now, it currently isn’t possible to use Conan in a 
non-intrusive way. That is, using it for fetching dependencies without adapting 
the build configuration to it.
I’ve opened up a pull request (as well as a fix) for this issue here [1].

I’ve implemented pure CMake-based package management solutions based on 
ExternalProject_Add() (using a Superbuild approach) in the past as well as 
using Conan for managing dependencies currently for a client of mine.
Based on my experience, I’m confident that really the only reason to use Conan 
is that it solves the persistence of binary artifacts for you. Since Conan uses 
a client/server architecture you typically have something like an Artifactory 
server where Conan is able to store and fetch precompiled packages for you. 
Currently, CMake doesn’t offer something like this, but I think it should be 
trivially to implement (think of CDash but for storing binary artifacts).
One issue I have with Conan is that you are forced to duplicate some of your 
build logic that in my point of view really belongs to the build system and not 
to your package management solution.


[1] https://github.com/conan-io/conan/issues/4467 
<https://github.com/conan-io/conan/issues/4467>
--
Kai Wolf
Kai Wolf - SW Consulting
www.kai-wolf.me <http://kai-wolf.me/>
XING <https://www.xing.com/profile/Kai_Wolf14> · LinkedIn 
<https://www.linkedin.com/in/kw0lf/> · GitHub <https://github.com/NewProggie>

> Am 19.02.2019 um 11:56 schrieb Craig Scott :
> 
> 
> 
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona  <mailto:tjwrona1...@gmail.com>> wrote:
> I have been working on a new C++ project and I am trying to decide whether I 
> should use CMake as my package management system or if I should use a 
> dedicated package management tool such as Conan.
> 
> For more information on Conan see: https://conan.io/ <https://conan.io/>
> 
> I am trying to understand the main difference between using Conan to manage 
> dependencies vs using CMakes "FetchContent" module. Are there any compelling 
> reasons to prefer something like Conan?
> 
> Excellent question, one that I think deserves a more detailed answer than I 
> can provide here, but I'll try to hit the main points as I see them.
> 
> Personally, I think there is no "right answer" or "one size fits all" when it 
> comes to package management for a CMake project. What works well for one 
> situation, person or project may not be as convenient or suitable for 
> another. There are competing needs and views, some of which are personal 
> preferences, others are hard requirements from things like OS distribution 
> policies for packaging. Even just the maturity of a project can have a big 
> influence on how developers may prefer to handle its dependencies and handle 
> it as a dependency of other projects.
> 
> The key thing for me is that the developer should ideally have choices when 
> it comes to this area. If a project hard-codes that its dependencies must 
> come from a particular provider (whether that be Conan, Hunter, vcpkg or some 
> other system), this might not be compatible with what the developer's 
> situation allows. You would need to weigh up whether it makes sense to lock 
> the developer into a particular package manager if they want to use your 
> project or not. An inappropriate choice here can mean lower adoption of the 
> project as some may reject it for consideration based on this point alone.
> 
> If instead a project relies only on find_package() to find its dependencies, 
> then it is up to the developer to ensure they are all available. This could 
> be done using whatever package manager the developer finds convenient, or 
> they could build the dependency projects from source individually or they 
> might set up a superbuild parent project that builds the dependencies in the 
> required order and makes dependees available to dependers. This gives good 
> flexibility at the cost of more responsibility on the developer than perhaps 
> some would want (again, it will be highly situation-dependent).
> 
> A drawback with find_package() is that it assumes you actually have a 
> packageable project. For a variety of reasons, this may not be the case. 
> Consider a large, complex project in its early stages and where multiple 
> teams are working on different subprojects which all get combined into some 
> larger whole. Each of the subprojects may need to be able to build on their 
> own with their own smaller subset of dependencies, but they also need to be 
> able to be incorporated into a larger build (think of different teams working 
> on core toolkits, rendering engines, different algorithm strategies, multiple 
> GUI applications, backend components, etc). No-one may know y

Re: [CMake] [cmake-developers] Using CMake as a package manager vs using a dedicated package management tool (like Conan)

[Kai Wolf]

Well, as of right now, it currently isn’t possible to use Conan in a 
non-intrusive way. That is, using it for fetching dependencies without adapting 
the build configuration to it.
I’ve opened up a pull request (as well as a fix) for this issue here [1].

I’ve implemented pure CMake-based package management solutions based on 
ExternalProject_Add() (using a Superbuild approach) in the past as well as 
using Conan for managing dependencies currently for a client of mine.
Based on my experience, I’m confident that really the only reason to use Conan 
is that it solves the persistence of binary artifacts for you. Since Conan uses 
a client/server architecture you typically have something like an Artifactory 
server where Conan is able to store and fetch precompiled packages for you. 
Currently, CMake doesn’t offer something like this, but I think it should be 
trivially to implement (think of CDash but for storing binary artifacts).
One issue I have with Conan is that you are forced to duplicate some of your 
build logic that in my point of view really belongs to the build system and not 
to your package management solution.


[1] https://github.com/conan-io/conan/issues/4467
--
Kai Wolf
Kai Wolf - SW Consulting
www.kai-wolf.me <http://kai-wolf.me/>
XING <https://www.xing.com/profile/Kai_Wolf14> · LinkedIn 
<https://www.linkedin.com/in/kw0lf/> · GitHub <https://github.com/NewProggie>

> Am 19.02.2019 um 11:56 schrieb Craig Scott :
> 
> 
> 
> On Tue, Feb 19, 2019 at 12:46 PM Timothy Wrona  <mailto:tjwrona1...@gmail.com>> wrote:
> I have been working on a new C++ project and I am trying to decide whether I 
> should use CMake as my package management system or if I should use a 
> dedicated package management tool such as Conan.
> 
> For more information on Conan see: https://conan.io/ <https://conan.io/>
> 
> I am trying to understand the main difference between using Conan to manage 
> dependencies vs using CMakes "FetchContent" module. Are there any compelling 
> reasons to prefer something like Conan?
> 
> Excellent question, one that I think deserves a more detailed answer than I 
> can provide here, but I'll try to hit the main points as I see them.
> 
> Personally, I think there is no "right answer" or "one size fits all" when it 
> comes to package management for a CMake project. What works well for one 
> situation, person or project may not be as convenient or suitable for 
> another. There are competing needs and views, some of which are personal 
> preferences, others are hard requirements from things like OS distribution 
> policies for packaging. Even just the maturity of a project can have a big 
> influence on how developers may prefer to handle its dependencies and handle 
> it as a dependency of other projects.
> 
> The key thing for me is that the developer should ideally have choices when 
> it comes to this area. If a project hard-codes that its dependencies must 
> come from a particular provider (whether that be Conan, Hunter, vcpkg or some 
> other system), this might not be compatible with what the developer's 
> situation allows. You would need to weigh up whether it makes sense to lock 
> the developer into a particular package manager if they want to use your 
> project or not. An inappropriate choice here can mean lower adoption of the 
> project as some may reject it for consideration based on this point alone.
> 
> If instead a project relies only on find_package() to find its dependencies, 
> then it is up to the developer to ensure they are all available. This could 
> be done using whatever package manager the developer finds convenient, or 
> they could build the dependency projects from source individually or they 
> might set up a superbuild parent project that builds the dependencies in the 
> required order and makes dependees available to dependers. This gives good 
> flexibility at the cost of more responsibility on the developer than perhaps 
> some would want (again, it will be highly situation-dependent).
> 
> A drawback with find_package() is that it assumes you actually have a 
> packageable project. For a variety of reasons, this may not be the case. 
> Consider a large, complex project in its early stages and where multiple 
> teams are working on different subprojects which all get combined into some 
> larger whole. Each of the subprojects may need to be able to build on their 
> own with their own smaller subset of dependencies, but they also need to be 
> able to be incorporated into a larger build (think of different teams working 
> on core toolkits, rendering engines, different algorithm strategies, multiple 
> GUI applications, backend components, etc). No-one may know yet how it should 
> get packaged up and every

Re: [CMake] Get linker flags / include directories for a library target

[Kai Wolf]

You can ask a CMake build target for its properties using get_target_property().
For instance, to retrieve the linker flags for a given target foo, you’d write:

get_target_prooperty(foo_linker_flags foo LINK_FLAGS)

See [1] for a list of valid parameters.

Greetings,

Kai

[1] 
https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html#properties-on-targets

http://kai-wolf.me
http://effective-cmake.com

> Am 20.12.2018 um 23:14 schrieb Unknown :
> 
> Dear community,
> 
> I have been wondering on multiple occasions about how to get the
> linker flags (i.e. all -llib -Ldir) and include flags (-Idir)
> for a library (i.e. a target added to the project using
> add_library) within a cmake.
> 
> There are many cases in which the flags are required, noticeably
> generating a suitable pkg-config file or creating a wrappers around
> C/C++ libraries.
> 
> I think that it should be possible to derive the flags from
> some of the target properties of the library, but I don't
> know exactly how.
> 
> Could you give me a hand?
> 
> ax487
> 
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ 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



signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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] ExternalProject, Superbuild and rebuild on Windows

[Kai Wolf]

The CMAKE_BUILD_TYPE variable only makes sense for single-configuration 
generators (such as Makefile or Ninja) and is not used for IDE type generators.
You should rather look for CMAKE_CONFIGURATION_TYPES as well as 
CMAKE_CFG_INTDIR.

Greetings,

Kai

http://kai-wolf.me
http://effective-cmake.com


> Am 20.12.2018 um 12:09 schrieb Romain LEGUAY :
> 
> Hello everyone,
> 
> I'm trying to build VTK and ITK along my project.
> 
> For now, I use the trick to add an option to build VTK and ITK only once 
> using ExternalProject_Add for all my dependencies and also for my project.
> 
> This works great on Unix system but with a VS solution, the dependencies are 
> not rebuilt when I change CMAKE_BUILD_TYPE.
> 
> Is it possible to know if CMAKE_BUILD_TYPE is changed? It will permit me to 
> switch on the option to rebuild the dependencies.
> 
> Anyone as other better ideas?
> 
> Thank you
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ 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



signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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] Testing our CMake Modules

[Kai Wolf]

They (Kitware) typically write custom .cmake files to test the function/macro 
under test coupled together with a CMakeLists.txt file and/or a small C/C++ 
implementation file. Look here [1] for some examples, for instance 
CMake/Tests/MacroTest.

Greetings,

Kai

http://kai-wolf.me
http://effective-cmake.com

[1] https://github.com/Kitware/CMake/tree/master/Tests

> Am 10.12.2018 um 13:30 schrieb Ramold, Felix :
> 
> We created multiple additional functions for CMake. They became quite a lot, 
> and we need to (unit) test them.
> There are simple ones, that are only variable bases like:
> function(join_list LIST GLUE)
> These can be tested with a custom CMake Script, that checks the results. For 
> this we also wrote a set of assert-macros.
> This becomes way harder when the functions are target based:
> function(target_my_custom_property_set TARGET VALUE)
> We need a multiple CMakeLists.txt Files that need to be configured. 
> Configuration must succeed or fail with specified messages. Also the result 
> files must be checked.
> I wonder, is there an easier way? Is there a existing framework? How does 
> Kitware test the shipped modules?
> Note: My original Stackoverflow question: 
> https://stackoverflow.com/questions/51948060/testing-our-cmake-modules
> 
> Thanks,
> Felix
> --
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ 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



signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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] using ExternalProject_Add when cmake is launched

[Kai Wolf]

You probably need to manually add a dependency from your ExternalProject to
your target that needs the libraries.
For instance

ExternalProject_Add(fetch_win32_libs ...)
add_library(your_other_target ...)
add_dependencies(your_other_target fetch_win32_libs)

Greetings

Kai Wolf

http://kai-wolf.me/
kai.w...@gmail.com

2018-05-02 8:47 GMT+02:00 Stéphane Ancelot <sance...@numalliance.com>:

> Hi,
>
> I have got some win32 libraries dependencies stored in a project .
>
> Then I added ExternalProject_Add at beginning of my cmakelists file in
> order to clone this dependency to be available.
>
> and then provide the root path as follow:
>
> SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/JPEGLIB/jpegsrc-9c
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/zlib-1.2.3-lib
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/libpng-1.2.37-lib
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/ftgl-binary
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/freetype-dev_2.4.2-1
> ${CMAKE_CURRENT_SOURCE_DIR}/WIN32DEPS/iconv-1.9.2.1
> )
>
>
> unfortunately, the project is not cloned when cmake is launched and the
> next dependencies don't find the packages :-(
>
> What Can I do ?
>
> Regards,
>
> S.Ancelot
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Adding ignored tests to CTest XML output

[Kai Wolf]

Hi all,

when adding some ignored tests into the CTestCustom.cmake file via the
variable CTEST_CUSTOM_TESTS_IGNORE, I'd expect that those ignored tests
will also be written into the XML output file generated by CTest, so that
Jenkins or Teamcity is able to visualize this information.

However, it seems that even though the tests are indeed not executed when
running CTest, they're also not put into the XML file, for instance with
. Is this behaviour expected or am I missing
something?

Thanks in advance

Kai Wolf

http://kai-wolf.me/
kai.w...@gmail.com
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [CMake] [ANNOUNCE] CMake 3.11.0-rc3 is now ready for testing

[Kai Wolf]

Hey,

it’s nice to see that we’re now able to set include directories and compiler 
flags for imported targets as well apparently.
This means, no more

add_library(foo UNKNOWN IMPORTED)
set_target_properties(foo PROPERTIES
  INTERFACE_INCLUDE_DIRECTORIES …
  IMPORTED_LOCATION ..)

but using target_* just like for any other target as well

add_library(foo UNKNOWN IMPORTED)
target_include_directories(foo PUBLIC …)

However, reading through the 3.11 documentation [1] I think I’ve found a bug 
unfortunately:

"It is not possible to use an IMPORTED target in the left-hand-side of the 
target_compile_definitions(), target_include_directories(), 
target_compile_options() or target_link_libraries() commands, as that would be 
an attempt to modify it. IMPORTED targets are designed to be used only in the 
right-hand-side of those commands."

If that’s really the case, I will submit a patch for it right away. I just want 
to make sure, I’m not misunderstanding something here?

Greetings,

Kai Wolf
 <http://kai-wolf.me/> <http://kai-wolf.me/> 
<http://kai-wolf.me/>http://kai-wolf.me/ <http://kai-wolf.me/>

[1] 
https://cmake.org/cmake/help/v3.11/manual/cmake-buildsystem.7.html?highlight=right%20hand%20side#imported-targets

> Am 09.03.2018 um 20:00 schrieb Robert Maynard <robert.mayn...@kitware.com>:
> 
> I am proud to announce the third CMake 3.11 release candidate.
>  https://cmake.org/download/
> 
> Documentation is available at:
>  https://cmake.org/cmake/help/v3.11
> 
> Release notes appear below and are also published at
>  https://cmake.org/cmake/help/v3.11/release/3.11.html
> 
> Some of the more significant changes in CMake 3.11 are:
> 
> * The Makefile Generators and the "Ninja" generator learned to add
>  compiler launcher tools along with the compiler for the "Fortran"
>  language ("C", "CXX", and "CUDA" were supported previously). See the
>  "CMAKE__COMPILER_LAUNCHER" variable and
>  "_COMPILER_LAUNCHER" target property for details.
> 
> * Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
>  "generator expression" in target-wide "COMPILE_DEFINITIONS",
>  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
>  generator expression documentation for caveats.
> 
> * The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
>  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
>  "INCLUDE_DIRECTORIES".  It previously supported only
>  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
>  documentation for caveats.
> 
> * "add_library()" and "add_executable()" commands can now be called
>  without any sources and will not complain as long as sources are
>  added later via the "target_sources()" command.
> 
> * The "target_compile_definitions()" command learned to set the
>  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.
> 
> * The "target_compile_features()" command learned to set the
>  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.
> 
> * The "target_compile_options()" command learned to set the
>  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.
> 
> * The "target_include_directories()" command learned to set the
>  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.
> 
> * The "target_sources()" command learned to set the
>  "INTERFACE_SOURCES" property on Imported Targets.
> 
> * The "target_link_libraries()" command learned to set the
>  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.
> 
> * The "COMPILE_DEFINITIONS" source file property learned to support
>  "generator expressions".
> 
> * A "COMPILE_OPTIONS" source file property was added to manage list
>  of options to pass to the compiler.
> 
> * When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
>  parallel "moc" or "uic" processes to reduce the build time. A new
>  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
>  property may be set to specify the number of parallel "moc" or "uic"
>  processes to start.  The default is derived from the number of CPUs
>  on the host.
> 
> 
> CMake 3.11 Release Notes
> 
> 
> Changes made since CMake 3.10 include the following.
> 
> 
> New Features
> 
> 
> 
> Platforms
> 

Re: [CMake] using external library

[Kai Wolf]

Steph,

what you want to achieve is better known as a *Superbuild* in the CMake
world. You have several options here, but the most basic one is probably
the following:

You setup another repository which only builds all the external
dependencies (such as Qt) and put them in a predefined place. In your
actual project you could refer to those prebuilt libraries using the
CMAKE_PREFIX_PATH variable, which should point to the install directory
from your external build. This way all the external stuff will only be
build once (probably via CI) and all your developers don't need to build
all the dependencies themselves.

Regarding the external package introspection. You could use find_package()
to check, if the correct version of your external library has been found on
the system and just use it. In any other case you check for the _NOTFOUND
variable and set it up locally, with the installation target pointing to
the CMAKE_PREFIX_PATH as mentioned above.

On a personal note, I would not use such a build system layout myself, as
it quickly becomes unclear from where a dependency is coming from and if
the dependency has all the required flags and settings as needed for the
software project. So you might want to reconsider a more cleaner layout.
For inspiration you may have a look at the CMake configuration of the
OpenChemistry project [1].

Greetings

[1] https://github.com/OpenChemistry/openchemistry

Kai Wolf

http://kai-wolf.me/
kai.w...@gmail.com

2018-03-05 11:59 GMT+01:00 Stéphane Ancelot <sance...@numalliance.com>:

> Hi,
>
> I need some external libraries in my project (eg a particular version of
> qt..)
>
> These external projects have been cloned locally , I could use
> ExternalProject_Add to clone it in my project.
>
> My major problem is that I will compile it each time and this is time and
> disk usage  consuming, for each users .
>
> I sounds to me better to have the compiled version available in my
> development system and use only header+binaries of this particular release.
>
> So, the scenario I would like to obtain :
>
> check if My Qt5 binaries are setted up in my system in a predefined
> directory (to not overlap with possible system one), if not setted up, then
>
> clone qt needed release and install it in my predefined system directory
> once (like /usr/local or a directory shared between users) .
>
> I hope you understood and it is enough clear 
>
> Thanks
>
> Steph
>
>
>
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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] [blog article] It's Time To Do CMake Right

[Kai Wolf]

​Well, sounds like a reasonably sized C++ project :-)

On a more serious note: Are you aware of so called Superbuilds? This is a
term that is used quite often in the context of large CMake based
dependency builds. Speaking from personal experience, I've found that
Superbuild projects do scale quite well and managing a large set of
(external) thirdparty dependencies is usually not as bad as it might look.

Greetings,

Kai Wolf
<http://kai-wolf.me/> <http://kai-wolf.me/> <http://kai-wolf.me/>
<http://kai-wolf.me/> http://kai-wolf.me/


2018-02-20 15:41 GMT+01:00 Boudewijn Rempt <b...@valdyas.org>:

> On Tuesday, 20 February 2018 14:59:10 CET Kai Wolf wrote:
> >  Nice,
> >
> > ​I've found a smaller issue though. I've just submitted a PR on GitHub.
> > The reddit discussion is also interesting. A common theme in the typical
> > "CMake is bad" discussions is not the lack of documentation​, but a good
> > tutorial on how to *actually accomplish things* using CMake in a correct
> > and scalable manner.
>
> I've used cmake since 2006, and I am completely in a fog when it comes to
> how
> I should update my project (which has a couple of hundred cmakelists.txt
> files, thirty external cmake projects and oodles of libraries and plugins)
> to
> something more modern...
>
> > As a shameless self-plug: I am currently writing a book[1] on exact this
> > topic and really hope, I'll be able to release it by summer 2018 :-(
>
> Well, put me down for three copies!
>
> --
> Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ 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
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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] [blog article] It's Time To Do CMake Right

[Kai Wolf]

 Nice,

​I've found a smaller issue though. I've just submitted a PR on GitHub.
The reddit discussion is also interesting. A common theme in the typical
"CMake is bad" discussions is not the lack of documentation​, but a good
tutorial on how to *actually accomplish things* using CMake in a correct
and scalabale manner.
As a shameless self-plug: I am currently writing a book[1] on exact this
topic and really hope, I'll be able to release it by summer 2018 :-(

Greetings,

Kai

[1] http://effective-cmake.com/

<https://github.com/NewProggie>

2018-02-20 14:38 GMT+01:00 Kai Wolf <m...@kai-wolf.me>:

> Nice,
>
> ​I've found a smaller issue though. I've just submitted a PR on GitHub.
> The reddit discussion is also interesting. A common theme in the typical
> "CMake is bad" discussions is not the lack of documentation​, but a good
> tutorial on how to *actually accomplish things* using CMake in a correct
> and scalabale manner.
> As a shameless self-plug: I am currently writing a book[1] on exact this
> topic and really hope, I'll be able to release it by summer 2018 :-(
>
> Greetings,
>
> Kai
>
> [1] http://effective-cmake.com/
>
>
> 2018-02-20 14:12 GMT+01:00 Cristian Adam <cristian.a...@gmail.com>:
>
>> Hi,
>>
>> I thought the audience here would appreciate this:
>> https://pabloariasal.github.io/2018/02/19/its-time-to-do-cmake-right/
>>
>> It did quite a stir on /r/cpp too:
>> https://www.reddit.com/r/cpp/comments/7yps20/its_time_to_do_cmake_right/
>>
>> Cheers,
>> Cristian.
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ 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
>>
>>
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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] [RFC] rewriting FindMKL

[Kai Wolf]

I've fixed some (mentioned) issues already and opened up a PR on
GitHub. You might want to check that out, otherwise I'll just delete
my PR.


2018-01-22 22:20 GMT+01:00 Alexander Neundorf :
> On 2018 M01 22, Mon 15:16:50 CET Sik wrote:
>> Hello CMake users and devs,
>>
>> In openmeeg we are reviewing our MKL package finder to make it more
>> maintainable for ourselves and others who had adopted our solution.
>> Therefore I'm writing you requesting comments and feedback so that is
>> useful for everyone.
>>
>> Here is the project we have set up in order to test it. It has a simple
>> example using MKL and CI for different scenarios.
>>
>> https://github.com/openmeeg/findmkl_cmake
>
> that's quite a lot of stuff, I'll try to test itin the next days.
>
> Just a few quick comments:
>
> The MESSAGE() in line 39 is ALL_UPPERCASE.
>
> MKL_ROOT_DIR from line 31 is put into the cache, reusing the same variable
> name in line 35 probably works, but the interaction between cache- and non-
> cache variables is somewhat complicated, so I would recommend to use different
> names.
>
> When searching mkl_cblas.h in line 31, in case the Intel compiler is used, the
> install directory of CMAKE_CXX_COMPILER could be used in some way as a hint to
> help finding MKL.
>
> I don't like the error message in line 39, I usually prefer using
> CMAKE_PREFIX_PATH.
>
> Lines 87 to 95 are not correctly indented, also lines 105 to 112.
>
> Is BLA_STATIC in line 117 correct, or is this a typo ?
>
> Alex
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ 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
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] How to include external (shared) library with several dlls/dylibs

[Kai Wolf]

Hi,

I need to integrate an externally built (shared) library as a logical
build target into my CMake configuration which consists of several
shared library files (dlls/dylibs).
Usually I'd do the following:

find_path(MyLib_INCLUDE_DIR mylib.h HINTS ${MyLib_PATH}/include)
find_library(MyLib_LIBRARY NAMES MyLib HINTS ${MyLib_PATH}/bin)
find_library(MyLib_LIBRARY_DEBUG NAMES MyLib_d ${MyLib_PATH}/bin)

include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(MyLib DEFAULT_MSG
  MyLib_LIBRARY MyLib_LIBRARY_DEBUG MyLib_INCLUDE_DIR)

if(MyLib_FOUND AND NOT TARGET MyLib::MyLib)
  set(MyLib_LIBRARIES ${MyLib_LIBRARY})
  set(MyLib_INCLUDE_DIRS ${MyLib_INCLUDE_DIR})

  add_library(MyLib::MyLib UNKNOWN IMPORTED)
  set_target_properties(MyLib::MyLib PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES ${MyLib_INCLUDE_DIR}
IMPORTED_LOCATION ${MyLib_LIBRARY}
IMPORTED_LOCATION_DEBUG ${MyLib_LIBRARY_DEBUG})

mark_as_advanced(MyLib_INCLUDE_DIR MyLib_LIBRARY MyLib_LIBRARY_DEBUG)
endif()

My understanding is that add_library(... UNKOWN IMPORTED) will CMake
figure out shared/static libraries by itself (and based on the option
BUILD_SHARED_LIBS probably, but this shouldn't be necessary). However,
CMake doesn't allow to add a list of libraries to the property
IMPORTED_LOCATION. For Instance, in case I want to import MyLib,
MyLibFoo and MyLibBar both as debug and release builds, this is not
possible using the listed approach.

I'm aware of add_library(MyLib::MyLib INTERFACE IMPORTED) and set a
list of libraries to the property INTERFACE_LINK_LIBRARIES, but this
is problematic in the case of creating relocatable packages (as
mentioned in the CMake documentation). Furthermore, there's no such
property as INTERFACE_LINK_LIBRARIES_DEBUG, thus it would only be
possible to refer to either the release or debug builds of my
externally imported library.

So, how am I supposed to import my externally built library as an
relocatable-ready logical CMake target which actually includes several
either debug or release build shared library files?

Thanks in advance.
-- 

Powered by www.kitware.com

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

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

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

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

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

[CMake] Concerning IDE support for superbuilds

[Kai Wolf]

Hi all,

a common approach for dealing with larger dependencies in a project is using a 
superbuild approach, where all dependencies get downloaded in a separate 
repository using ExternalProject_Add() and the actual project is included as a 
sub repository (e.g. using git submodules) and also build as an external 
project [1], [2], [3]. This is necessary since external projects don’t play 
well as a direct dependency for internal targets, as the external projects 
won’t be created and available until build time, whereas CMake needs some 
information already at configure time for creating a proper build system.

As discussed previously on this mailing list this approach has some significant 
drawbacks: Since the actual project is also build as an external project, CMake 
treats it as an external source respectively and IDE support is not available. 
One possible solution to this problem is to let the outer project generate a 
cache file which subsequently can be used in the actual project to configure 
all paths to the previously downloaded and built external dependencies:

++
|   Superbuild   |  > generates init-cache.cmake
++

++
| actual project |  > uses: cmake -C init-cache.cmake
++

However, this means we now need two steps to configure and build the actual 
project and also cannot easily maintain the external dependencies within one 
large project.

After thinking about this for a while I came up with the following hackish 
solution and would like to ask you, if you see any drawback in using this. 
Basically all I’m doing is to include the actual project first as a dummy 
external project and set the external projects as dependencies, thus they’ll 
get built beforehand and in the BUILD_COMMAND of the actual project I’m calling 
CMake to the project’s CMakeLists.txt again to trigger a reconfigure, writing a 
cache file and set a specific variable |project_deps_installed| which is used 
as an indicator in the CMakeLists. configuration to include the actual project 
via add_subdirectory(). For instance:

CMakeLists.txt:
option(BUILD_MYPROJECT „Build the actual project“ ON)
if(BUILD_MYPROJECT)
  if(project_deps_installed)
include(${CMAKE_CURRENT_BINARY_DIR}/init-cache.cmake)
add_subdirectory(MyProject)
  else()
include(External_project)
  endif()
endif()

External_project.cmake
ExternalProject_Add(MyProject
  SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/MyProject
  BUILD_COMMAND ${CMAKE_COMMAND} -E chdir ${CMAKE_CURRENT_BINARY_DIR}
${CMAKE_COMMAND} ${CMAKE_CURRENT_SOURCE_DIR}
  INSTALL_COMMAND „"
  DEPENDS ${external_deps})

write_cmake_cache_file(„${cache_script}“ „${cache_args}“)
set(project_deps_installed TRUE CACHE BOOL „“)

As a result, all external dependencies get build and installed via 
ExternalProject_Add() and the actual project is configured properly and 
included via add_subdirectory(), thus it can continue using find_package() as 
usual and will be pointed to the previously configured dependencies. So far, I 
haven’t found any downside to this and consider making this part of CMake 
itself, in case you don’t see any problems using this approach?


Thanks in advance for your input.


[1] https://github.com/OpenChemistry/openchemistry
[2] https://github.com/MITK/MITK
[3] https://github.com/SuperElastix/SuperElastix



signature.asc
Description: Message signed with OpenPGP
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ 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