Re: [cmake-developers] escape double quote in generated file

[Craig Scott]

On Sat, Aug 31, 2019 at 12:36 AM Eugene Karpov  wrote:

> Hello all,
>
> I'm working on a cross platform project. On Ubuntu I would like to save
> all the compiler options, definitions and other complier related stuff to a
> generated file to use it later for precompiled header generation.
> My issue is that I have to specify a macro that contain double quotes for
> g++ compiler visibility attribute. When I generate a file with double
> quotes they are not escaped. I also tried to use `string(replace "\""
> "\\\""...)` without effect.
> I've made simple two files project of a shared library to show the issue.
> It has only target compile definitions for simplicity.
>
> - CMakeLists.txt --
> cmake_minimum_required(VERSION 3.14)
> set(target test)
> project(${target})
> if(CMAKE_CXX_COMPILER_ID MATCHES "GNU|Clang")
> set(API_IMPORT_MACRO "__attribute__((visibility(\"default\")))")
> set(API_EXPORT_MACRO "__attribute__((visibility(\"default\")))")
> else()
> set(API_IMPORT_MACRO "__declspec(dllimport)")
> set(API_EXPORT_MACRO "__declspec(dllexport)")
> endif()
> function(export_all_flags _target _filename)
>   set(_compile_definitions
> "$")
>   set(_compile_definitions
> "$<$:-D$\n>")
>   file(GENERATE OUTPUT "${_filename}" CONTENT "${_compile_definitions}")
> endfunction()
> add_library(${target} SHARED test.cpp)
> target_compile_definitions(${target}
> PRIVATE API=${API_EXPORT_MACRO}
> INTERFACE API=${API_IMPORT_MACRO})
> export_all_flags(${target} ${CMAKE_BINARY_DIR}/flags.txt)
> - CMakeLists.txt --
> - test.cpp --
> void API test() {}
> - test.cpp --
>
> The result file "flags.txt" is following:
> -DAPI=__attribute__((visibility("default")))
>
> I would like any solution to make the result as:
> -DAPI=__attribute__((visibility(\"default\")))
>

Are you free to modify the headers where the API_IMPORT/API_EXPORT symbols
are used? If so, then it is far easier to delegate the definition of such a
symbol to a separate header file rather than try to define it directly on
the compiler command line. The GenerateExportHeader
<https://cmake.org/cmake/help/latest/module/GenerateExportHeader.html>
module provides a convenient way to create such a header and also set the
relevant details in your CMake target to do the right thing when building
and when consuming the library. I'd expect it to be suitable for a
precompiled header scenario too.

And shameless plug, if you're interested in this area (symbol visibility),
part of my upcoming CppCon talk <https://sched.co/SfnH> in a few weeks will
cover exactly this topic. ;)

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

Re: [cmake-developers] Is email notification of a failed CMake dashboard possible?

[Craig Scott]

Notifications for builds are controlled through CDash. You can adjust your
CDash notifications to suit your preferences. Go to CDash, click on "My
CDash". You should see a list of "My Projects" and "Public Projects".
Subscribe to a project and it will appear under your "My Projects" area if
it isn't there already. For each subscribed project, you should see an icon
next to it under the Actions column which allows you to edit your
subscription and from there you can control what you receive email
notifications for. I'm not sure if there is a way to limit your
notifications to just certain sites though. You may need to ask on the
CDash mailing list for help with that.


On Sun, May 26, 2019 at 7:54 AM Alan W. Irwin 
wrote:

> With a lot of initial configuration help from Brad King, I have been
> automatically submitting a Nightly dashboard for CMake (including the
> PLplot contract test) for some time now (see the "merlin" results at
> <https://open.cdash.org/index.php?project=CMake> and
> <https://open.cdash.org/index.php?project=KWSys>).  On extremely rare
> occasions there is a failure in either of my CMake or KWSYS
> dashboards.  Is it possible for me to set up e-mail notification of
> such failures (and successes at first to make sure notification
> works), and if so, how?
>
> Alan
> __
> Alan W. Irwin
>
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (freeeos.sf.net); the Time
> Ephemerides project (timeephem.sf.net); PLplot scientific plotting
> software package (plplot.org); the libLASi project
> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
> and the Linux Brochure Project (lbproject.sf.net).
> __
>
> Linux-powered Science
> __
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake-developers
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

Re: [cmake-developers] Problem with foreach() iteration over a list that uses generator expressions

[Craig Scott]

On Tue, May 7, 2019 at 12:27 AM Tadeusz A. Kadłubowski <
tadeusz.kadlubow...@pix4d.com> wrote:

> Hi,
>
> I have an `INTERFACE IMPORTED` library target that depends on a bunch
> of optional dependencies. Please see the snippet below:
>
> cmake_minimum_required(VERSION 3.14)
>
> add_library(example INTERFACE IMPORTED)
> set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
> $<$:${undefined_dependency_one}
> ${undefined_dependency_two}>
> )
>

If your generator expression contains spaces, you need to surround the
whole expression with quotes:

set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES

"$<$:${undefined_dependency_one} ${undefined_dependency_two}>"
)

Note that in this case, the space is unlikely to actually be what you want
because the above would end up adding a single library named

"${undefined_dependency_one} ${undefined_dependency_two}"



> It so happens that both of the optional dependencies
> `${undefined_dependency_one}` and `${undefined_dependency_two}` are
> set to empty/undefined on my system, which is perfectly fine.
>
> I want to do some postprocessing to the dependencies  of my target:
>
> get_target_property(all_dependencies example INTERFACE_LINK_LIBRARIES)
> foreach(lib IN LISTS all_dependencies)
> message(STATUS "dependency on " ${lib})
> endforeach()
>
> This `foreach()` loop gets confused about the generator expression.
> The output of the `message(STATUS ...)` calls in the snippet above is:
>
> -- dependency on $<$:
> -- dependency on >
>
> Please note that the generator expression got mangled into two pieces
> by the `foreach()` loop. I was expecting to see a single line of
> `$<$:>`
>
> I experimented with different versions of this test case and found
> variants that do not get mangled in the `foreach()` loop. In a
> modification when there is only one empty/undefined dependency the
> `foreach()` loop works as expected.
>
> set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
> $<$:${undefined_dependency_one}>
> )
>
> A modification in which each empty/undefined dependency is surrounded
> with its own generator expression works correctly too:
>
> set_property(TARGET example PROPERTY INTERFACE_LINK_LIBRARIES
> $<$:${undefined_dependency_one}>
> $<$:${undefined_dependency_two}>
> )
>

This would be the way to achieve what you seem to be wanting to do.



>
> Is that a bug in how CMake handles generator expressions? Am I
> misunderstanding some CMake language concepts here?
>
> (all code tested with CMake 3.14.3 on Ubuntu 18.04)
>
> I would be grateful on any feedback about what's going on in that
> `foreach` loop.
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

[cmake-developers] CMAKE_XCODE_GENERATE_SCHEME still documented as experimental

[Craig Scott]

The CMAKE_XCODE_GENERATE_SCHEME variable has been available in CMake since
about the 3.9 release. Its documentation states that the Xcode Schema
Generator is still experimental and subject to change, but is this still
the case? Would it be appropriate to remove that note from the docs now?

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

Re: [cmake-developers] Using FetchContent fails when two subprojects have a target with the same name

[Craig Scott]

On Wed, Feb 20, 2019 at 3:36 PM Timothy Wrona  wrote:

> (Included cmake-developers list as well in case this may have just been
> something that should work that was overlooked with the FetchContent module)
>
> On Tue, Feb 19, 2019 at 11:32 PM Timothy Wrona 
> wrote:
>
>> I am having an issue with using FetchContent to grab two subprojects that
>> both contain a "doxygen" target to build the documentation.
>>
>> Both of these subprojects need to be able to be built independently and
>> when built on their own they compile fine (along with their documentation),
>> but when I pull them into one project using "FetchContent" I get an error
>> saying I can't define the "doxygen" target more than once.
>>
>> I imagine this kind of issue would come up all of the time when using a
>> "superbuild" pattern. Is there a typical way of handling this?
>>
>
I thought this limitation was already mentioned in the FetchContent docs,
but it seems it isn't. If two different dependencies define the same global
target name, then they cannot be combined into the same build via
add_subdirectory(). CMake doesn't allow a target to be redefined (although
it does allow additional commands to be added to an existing custom
target). I'll try to add some docs to FetchContent to mention this
limitation, but they will not make it into the 3.14 release - the
limitation has always been there right from when FetchContent was first
introduced in 3.11.

A traditional superbuild that uses ExternalProject won't have a problem
with this because a subproject's own targets are not combined with targets
of other subprojects into a single build. Instead, the top level project
only sees the targets that ExternalProject itself creates. This is most
likely the best workaround if you are not able to modify the target names
used in the subprojects you want to combine.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

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

[Craig Scott]

work in them)? What will be the impact on developers working on the project
   when these dependencies need to be updated (how easy is it for them to
   update, what assumptions are you making about their development environment
   and tools)?
   - What breadth of platforms, compilers and CMake generators do you want
   to support? The bigger this set, the more it may drive you towards building
   dependencies from source rather than relying on having pre-built packages
   available to you.
   - Do you want developers to be able to use tools like sanitizers,
   perform code refactoring across projects or have source code visibility
   into dependencies within their IDE tools? FetchContent supports all of
   these requirements quite naturally, but doing so for the other methods it
   may be more difficult.
   - How will you manage repeatability of building past releases? Will you
   be able to build a year old release again if you update a build slave? In
   particular, what assumptions are you making about a CI system's build
   slaves and what dependencies they have installed (can you have multiple
   versions of any given dependency available at once, whether that be at a
   known path or via whatever package manager(s) you choose to use)?


On a side note, this is an area I'm increasingly thinking about these days
(I'm the author of the FetchContent module). I'm interested in hearing
peoples' views on dependency management and building an understanding of
what works for people and what doesn't. If you want to send feedback my
way, do feel free to get in touch.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

Re: [cmake-developers] Shared library under Windows and CMake: DLL not found before installation

[Craig Scott]

On Thu, Feb 7, 2019 at 7:11 AM Brad King via cmake-developers <
cmake-developers@cmake.org> wrote:

> On 2/6/19 2:40 PM, Joachim Wuttke wrote:
> > And combine it with
> >
> > ```
> > link_directories(BEFORE ${PROJECT_BINARY_DIR}/bin)
> > ```
> >
> > so that tests find the libraries?
>
> No.  CMAKE_RUNTIME_OUTPUT_DIRECTORY only affects the locations of
> the .dll files, not .a/.so/.lib.  Also CMake already knows where
> the library files will be and links via absolute path.  Link
> directories are almost never needed.
>
> > Anyway, my problem is not at link time, but when _executing_ a test.
> > Is there a canonical way of manipulating the Windows PATH from CMake?
>
> No.  In general one should not depend on PATH for .dll locations
> within your own project.
>

That's probably a bit strong, for very large projects it can be quite
inconvenient to have to put all executables and DLLs in the same directory.
For some scenarios, it's not a viable choice (can depend on the project's
directory layout requirements). There are a few ways to get this to work
for different scenarios, some depending on a more recent CMake version. For
tests run through CTest, The ENVIRONMENT test property can be used to
augment PATH on a test-by-test basis. For running under the Visual Studio
debugger, CMake 3.13 added the VS_DEBUGGER_ENVIRONMENT target property
which again can be used to set the PATH for a particular test executable
when run from within the VS IDE. If you need to support an older CMake
version, an equivalent functionality can be achieved with CMake 3.8 or
later using the VS_USER_PROPS target property, but this is more involved.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

Get the hand-book for every CMake user: Professional CMake: A Practical
Guide <https://crascit.com/professional-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-developers

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Craig Scott]

On Mon, Dec 10, 2018 at 7:57 PM Eric Noulard  wrote:

>
> Le dim. 9 déc. 2018 à 12:24, Craig Scott  a
> écrit :
>
>> On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki 
>> wrote:
>>
>>> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
>>> >
>>> > My assumption are:
>>> >  a) when you cross-compile your build is a "whole" and you shouldn't
>>> have to setup some superbuild
>>> >structure for building host tools ht_exe and another for target1
>>> tool t1t_exe and another one for target2 tool t2t_exe.
>>> >
>>> >  b) what you want is to build:
>>> >  ht_exe for the host
>>> >  possibly use ht_exe during the build to generate some [source]
>>> file
>>> >  t1t_exe for the [cross]target1
>>> >  t2t_exe for the [cross]target2
>>> >
>>> >  c)  you seldomly compile the same source for the host AND the target,
>>> but it may happen.
>>>
>>> In case, you are doing unit tests, it’s normal to have the same code
>>> running in a test on the host platform and in the final binary on the
>>> target.
>>>
>>> I think, having more than 1 target platform becomes more and more normal
>>> as it becomes more usual to have multiple microcontrollers in a project.
>>>
>>
> Yes that's why I thought it was worth going further than host + target,
> but host + tgt1 + tg2 + 
>
>
>>
>>> Previously, I have encoded this in the build type. So instead of just
>>> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
>>> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
>>> much, that I have to run CMake 3 times to get all the binaries for a
>>> release build. The problem that I have, are dependencies between this
>>> builds. If I write a tool that (for example) generates source files for one
>>> of the target platforms, the build for the host platform must run before
>>> the build for that target platform. And when I make changes to that tool, I
>>> want the build to regenerate the generated source files.
>>>
>>> Keeping track of this dependencies to solve this kind of ordering issues
>>> and to allow minimum rebuilds, is the main purpose of any build system. To
>>> solve this with CMake, I think we need a way to define the dependencies
>>> between build types (in the example above, from the generator from the host
>>> build to the generated source file in one of the target builds) and CMake
>>> needs to know the build directory for all build types (not only the
>>> current).
>>>
>>
>> Perhaps a superbuild would be the cleanest approach here? The host tools
>> would be one subproject and the cross-compile builds would depend on the
>> host tools' build. You could then choose to build everything via the top
>> level superbuild or just work on one of the subprojects if that's all you
>> needed once the initial tools build had been done. You could even set up as
>> many different sub-projects for the different architectures as needed.
>> Packaging would require a little more work, but it shouldn't be
>> prohibitively so.
>>
>
> I guess the tough part is to find a [light] way to specify dependencies
> between host target build and the various target builds.
>
>
>> Another alternative is the approach described in this stackoverflow
>> article
>> <https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
>> which performs the host tools build off to the side in a secondary build
>> during configure. This works well when the host tools don't change much (we
>> use it extensively at work with very large, complex hierarchical projects).
>> It wouldn't help though if you need to build more than one cross-compiled
>> architecture.
>>
>> > The wish-season is coming up, so that's sort of what I would like to
>>> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>>>
>>> How about ``add_dependencies()`` allowing me to define dependencies
>>> between different build types? :-)
>>>
>>
>> A superbuild would already give you the equivalent capability.
>>
>
> Not as easy as it seems right?
> I bet you know it well as you listed the dependencies shortcoming of
> adding dependencies for External_ProjectAdd in your book (§27.1.4).
>

For a strict superbuild arrangement, handling straight dependencies to get
build orde

Re: [cmake-developers] [CMake] dependencies of cross compiliations

[Craig Scott]

On Tue, Dec 4, 2018 at 6:56 PM Torsten Robitzki  wrote:

> > Am 27.11.2018 um 19:55 schrieb Eric Noulard :
> >
> > However from my point of view and my cross-compiling experience when you
> cross-compile you have:
> >
> > 1) the host compiler which is used to compile "host tools"
> > 2) the target compiler (may be several of them) to "cross-compile"
> >
> > My assumption are:
> >  a) when you cross-compile your build is a "whole" and you shouldn't
> have to setup some superbuild
> >structure for building host tools ht_exe and another for target1 tool
> t1t_exe and another one for target2 tool t2t_exe.
> >
> >  b) what you want is to build:
> >  ht_exe for the host
> >  possibly use ht_exe during the build to generate some [source] file
> >  t1t_exe for the [cross]target1
> >  t2t_exe for the [cross]target2
> >
> >  c)  you seldomly compile the same source for the host AND the target,
> but it may happen.
>
> In case, you are doing unit tests, it’s normal to have the same code
> running in a test on the host platform and in the final binary on the
> target.
>
> I think, having more than 1 target platform becomes more and more normal
> as it becomes more usual to have multiple microcontrollers in a project.
>
> Previously, I have encoded this in the build type. So instead of just
> having Debug and Release, I had HOST_Debug, HOST_Release NRF51_Debug,
> NRF51_Release, STM8_Debug, STM8_Release and so on. It doesn’t annoy me very
> much, that I have to run CMake 3 times to get all the binaries for a
> release build. The problem that I have, are dependencies between this
> builds. If I write a tool that (for example) generates source files for one
> of the target platforms, the build for the host platform must run before
> the build for that target platform. And when I make changes to that tool, I
> want the build to regenerate the generated source files.
>
> Keeping track of this dependencies to solve this kind of ordering issues
> and to allow minimum rebuilds, is the main purpose of any build system. To
> solve this with CMake, I think we need a way to define the dependencies
> between build types (in the example above, from the generator from the host
> build to the generated source file in one of the target builds) and CMake
> needs to know the build directory for all build types (not only the
> current).
>

Perhaps a superbuild would be the cleanest approach here? The host tools
would be one subproject and the cross-compile builds would depend on the
host tools' build. You could then choose to build everything via the top
level superbuild or just work on one of the subprojects if that's all you
needed once the initial tools build had been done. You could even set up as
many different sub-projects for the different architectures as needed.
Packaging would require a little more work, but it shouldn't be
prohibitively so.

Another alternative is the approach described in this stackoverflow article
<https://stackoverflow.com/questions/36084785/building-a-tool-immediately-so-it-can-be-used-later-in-same-cmake-run>
which performs the host tools build off to the side in a secondary build
during configure. This works well when the host tools don't change much (we
use it extensively at work with very large, complex hierarchical projects).
It wouldn't help though if you need to build more than one cross-compiled
architecture.



> > The wish-season is coming up, so that's sort of what I would like to
> > have. Now it's your turn. No bikeshedding please, only deliveries ;)
>
> How about ``add_dependencies()`` allowing me to define dependencies
> between different build types? :-)
>

A superbuild would already give you the equivalent capability.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] [CMake] [MSVC] Setting warning level on target feels like long-time bug

[Craig Scott]

>From what I understand from a very limited quick search just now, it seems
that /W3 is the default warning level for Visual Studio (according to
the Microsoft
docs
<https://docs.microsoft.com/en-us/cpp/build/reference/compiler-option-warning-level?view=vs-2017>),
but CMake explicitly adds it
<https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/Windows-MSVC.cmake#L360>
as a default compiler flag in CMAKE__FLAGS_INIT. This makes me wonder
if it has always been the default, otherwise it isn't clear why it was
deemed necessary to add it. More to the point, unless there's a reason not
to, perhaps we could consider removing it from the default flags CMake
sets. I think this would largely address the situation you're describing
and shouldn't actually change the behavior of existing projects. I've CC'ed
the developer's list and suggest that follow-up discussion should occur
there.


On Sun, Dec 9, 2018 at 8:07 AM Mateusz Loskot  wrote:

> Hi,
>
> I define a target for a library, and set warning level for MSVC compiler:
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> Although this works well, the compiler throws this warning:
>
> cl : Command line warning D9025: overriding '/W3' with '/W4'
>
> I want to get rid of this warning, so I fix it this way
>
> if(MSVC)
>   string(REGEX REPLACE "/W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
>   string(REGEX REPLACE "-W3" "" CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS})
> endif()
>
> target_compile_options(mylib PRIVATE $<$:-W4>)
>
> This works like charm, but leaves me with sour feeling that
> something is not right here.The REGEX REPLACE clean-up
> has become such a habit, it's almost canonical thing I do in
> all my CMake-based projects.
>
> Shouldn't CMake drop the default when target_compile_options is called?
> Is this behaviour by design, for MSVC?
> Could anyone help me to understand if this is actually a bug
> or am I misunderstanding anything?
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
> --
>
> 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
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] Preferred case for macro names?

[Craig Scott]

On Tue, Nov 13, 2018 at 9:51 AM Joachim Wuttke 
wrote:

> My understanding was that prevalent usage in modern CMake
> is all lowercase for function names, all uppercase for
> macro names. In this sense, I submitted a number of merge
> requests where function and macro names are normalized, and
> in
>https://gitlab.kitware.com/cmake/cmake/merge_requests/2607
> I suggest an explicit recommendation in the macro and
> function doc pages.
>
> Now I am learning from Craig Scott that the more recent
> convention is actually all lowercase for macros as well
> as for functions.
>

To be clear, my understanding is that in the past (many years ago),
uppercase tended to be common, but I don't see that used much these days
for functions, macros or built-in commands. The general sentiment seems to
be that uppercase tends to be a bit "shouty" now. I'm suggesting that if
we're going to bring some consistency to the docs, I propose that we just
go with lowercase everywhere (functions, macros, built-in commands and
examples).


Regarding the finer points of macros versus functions versus built-in
commands and establishing a convention, it's actually a bit difficult to
draw a hard line in behaviour across all three. Consider commands like
find_package() and project(). These are built-in commands, but they behave
like a macros in that they add variables to the calling scope (yes,
functions can do that too, but the primary reason to use macros is to
inject variables into the calling scope). Most built-in commands act more
like functions and do not modify the calling scope. Trying to decide
whether built-in commands act like macros and which do not and making them
upper or lowercase based on that is unlikely to be a distinction that most
users would make, so a mix of upper and lowercase for built-in commands
would be unexpected. A consequence of this is that having macros and
functions with differing case conventions would seem to create a potential
inconsistency with whatever convention is used for built-in commands. The
only way to really have consistency here would seem to be just use the one
case convention, for which lowercase seems to be the logical and
increasingly prevalent choice.



>
> Thus two requests for comments:
>
> - Shall the reference manual give a clear recommendation
> on preferred case, to stear the community away from the
> inherited anarchy?
>

The docs can be consistent throughout, but matters of style are ultimately
up to individual projects and their own coding conventions. Over time,
making the CMake docs present a consistent style will likely encourage
projects that don't have a convention of their own to adopt that style out
of familiarity.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

[cmake-developers] PIE flags on various platforms

[Craig Scott]

I'm currently reviewing a merge request
<https://gitlab.kitware.com/cmake/cmake/merge_requests/2465> that addresses
problems with creating PIE executables. Is anyone here sufficiently
familiar with Fuchsia, FreeBSD or NetBSD to be able to check whether the
right flags are being used there (look at the relevant
Modules/Platform/*.cmake file)? If there are other platform-specific issues
which may need to be considered for these, I'm interested in hearing about
those too (for the BSDs in particular, there seems to have been quite a bit
of activity in this area a couple of years ago).

Regards

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] Automatically set policies for shipped modules

[Craig Scott]

On Mon, Sep 17, 2018 at 9:07 PM Brad King  wrote:

> On 09/17/2018 04:01 AM, Rolf Eike Beer wrote:
> > I suggest that every module included from the CMake installation is
> > considered clean for whatever we do and automatically gets a policy
> > scope push/pop right from the C++ level.
>
> That's fine with me for policies like CMP0057 that affect the
> CMake language features.  We can't do that for every policy
> because some policies affect the way modules behave for the
> calling project.
>
> When include() or find_package() establishes the policy scope
> for the included module we can inject a few settings.
>

We may also need to be careful about CMP0011 (Included scripts do automatic
cmake_policy PUSH and POP), since that has come up before with regard to
why some modules needed explicit policy push-pop even though include()
would normally do that for us automatically.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] Documentation of version comparisons needs updating

[Craig Scott]

On Sun, Sep 16, 2018 at 6:57 AM Alan W. Irwin 
wrote:

> The current (3.12.2) "if" documentation says, e.g.,
>
> if( VERSION_LESS_EQUAL )
> Component-wise integer version number comparison (version format is
> major[.minor[.patch[.tweak]]]).
>
> But what happens if any component of the version string is not an
> integer, e.g.,
>
> cmake version 3.12.20180915-g6f04e
>
> for the latest git version used for the cmake dashboard.  It
> appears from the
>
> CMAKE_CACHE_PATCH_VERSION:INTERNAL=20180915
>
> CMakeCache.txt entry that the string "20180915-g6f04e" is reliably
> converted in that case to the integer 20180915, but does that reliable
> conversion also occur for the "if" VERSION comparisons?  And if so,
> shouldn't the "if" documentation say something about truncation of
> trailing non-integer parts of the version components?
>
> What has lead me to these two questions is I am trying to distinguish
> between the above version and 3.12.2, and since the documentation did
> not acknowledge what would be done when non-integer strings were appended
> to any of the integer components of the version string, I am concerned
> the component integers might be determined in an unreliable way for
> trailing non-integer string cases.
>
>

After checking the code to confirm the behavior, I've put up a merge
request with clarification of the docs. You can find it here:

https://gitlab.kitware.com/cmake/cmake/merge_requests/2393

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] Quiet option for cmake

[Craig Scott]

On Thu, Aug 23, 2018 at 8:02 PM, Craig Scott 
wrote:

>
>
> On Thu, Aug 23, 2018 at 4:40 AM, Brad King  wrote:
>
>> On 08/21/2018 05:04 PM, Craig Scott wrote:
>> > A user has recently been asking about reducing the output coming from a
>> > FetchContent population when nothing needs to be done
>> > Because this is implemented as a sub-build, you always see the following
>> >
>> > -- Configuring done
>> > -- Generating done
>> > -- Build files have been written to: ...
>>
>> Isn't that output coming from the invocation here:
>>
>>   https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/Modules/
>> FetchContent.cmake#L776-781
>>
>> rather than inside ExternalProject?
>>
>
> Yes, that is where I'd like to be able to use the proposed --quiet or
> --silent option.
>
>
>
>>
>> Why is that output not always captured?
>>
>
> If you capture it, then you don't get to see it until the command has
> completed. It can take non-trivial time and in some cases may require user
> input (e.g. to enter a password for a private SSH key). If you captured the
> output and the download hung for some reason, there would be no output to
> give any indication of where the download was up to. For cases where you
> don't expect problems, you can use the QUIET option and the output is
> indeed captured and only output at the end. This is the default because
> otherwise the output is rather noisy with all the ExternalProject step
> logging. But for cases where you need to investigate problems, you don't
> want the output captured.
>
> Now that I've said all that, I guess FetchContent could check if the
> output of a QUIET run was just the above-mentioned three lines and drop
> them to leave no output in that case. Might be the simpler solution.
> Furthermore, for the second execute_process() call a few lines after the
> one referenced above (which does the build stage of the sub-build), we
> could potentially make use of the logging verbosity improvements in MR
> 2129 <https://gitlab.kitware.com/cmake/cmake/merge_requests/2129> if/when
> it is done to further minimise the output of the "nothing to do" case.
>
>
Sorry, got my wires crossed a bit there. The QUIET option already fully
absorbs the output unless there's an error. I missed this in the original
issue that prompted this request. Let me go back to that issue and see if
there's really anything needed here after all.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] Quiet option for cmake

[Craig Scott]

On Thu, Aug 23, 2018 at 4:40 AM, Brad King  wrote:

> On 08/21/2018 05:04 PM, Craig Scott wrote:
> > A user has recently been asking about reducing the output coming from a
> > FetchContent population when nothing needs to be done
> > Because this is implemented as a sub-build, you always see the following
> >
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: ...
>
> Isn't that output coming from the invocation here:
>
>   https://gitlab.kitware.com/cmake/cmake/blob/v3.12.1/
> Modules/FetchContent.cmake#L776-781
>
> rather than inside ExternalProject?
>

Yes, that is where I'd like to be able to use the proposed --quiet or
--silent option.



>
> Why is that output not always captured?
>

If you capture it, then you don't get to see it until the command has
completed. It can take non-trivial time and in some cases may require user
input (e.g. to enter a password for a private SSH key). If you captured the
output and the download hung for some reason, there would be no output to
give any indication of where the download was up to. For cases where you
don't expect problems, you can use the QUIET option and the output is
indeed captured and only output at the end. This is the default because
otherwise the output is rather noisy with all the ExternalProject step
logging. But for cases where you need to investigate problems, you don't
want the output captured.

Now that I've said all that, I guess FetchContent could check if the output
of a QUIET run was just the above-mentioned three lines and drop them to
leave no output in that case. Might be the simpler solution. Furthermore,
for the second execute_process() call a few lines after the one referenced
above (which does the build stage of the sub-build), we could potentially
make use of the logging verbosity improvements in MR 2129
<https://gitlab.kitware.com/cmake/cmake/merge_requests/2129> if/when it is
done to further minimise the output of the "nothing to do" case.


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?

[Craig Scott]

On Wed, Aug 22, 2018 at 1:39 PM, Ian Henriksen <
insertinterestingnameh...@gmail.com> wrote:

>
>
> On Tue, Aug 21, 2018 at 6:40 PM Craig Scott 
> wrote:
>
>>
>> On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey 
>> wrote:
>>
>>> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott 
>>> wrote:
>>> > Excuse the brevity, but it sounds like you might be looking for the
>>> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
>>> let me know why it isn't appropriate if so). See the following article for
>>> a more complete overview of this and related properties:
>>> >
>>> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
>>>
>>> Unfortunately that's not the same. Extensions manage C++ language
>>> features and STL capabilities, but -stdlib is for selecting an STL
>>> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
>>> to clang).
>>>
>>
>> Sorry, yes I misunderstood your problem. After a little digging, it seems
>> like you probably shouldn't be using the -stdlib option on Linux
>> <https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for
>> Android, the roadmap
>> <https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md>
>> is converging on a single STL implementation too.
>>
>
> All that first link says is that -stdlib is a flag that is specific to
> clang and that it shouldn't be used with gcc. You can use clang on Linux
> with either libstdc++ or libc++. I often use libc++ on Linux by setting
> CMAKE_CXX_FLAGS on the command line, though I'll admit that for me it's
> usually just to check if problems that come up are OS dependent, compiler
> dependent, or standard library dependent. You have to be careful since
> libstdc++ and libc++ have incompatible ABIs, but it's a useful feature.
> That said, I have no idea if specifying the standard library implementation
> merits handling at the CMake level since only clang supports switching
> anyway.
>


Good clarification, thanks. I was only thinking GCC on Linux and wasn't
considering clang (which was a bit dumb on my part - blame the lack of
coffee early in the morning ;) ).

Getting back to Robert's original query, the only part of the CMake code
base that I can see attempting to account for a -stdlib option is for
detection of gcc include paths, and this is only for Eclipse and CodeBlocks
generators (according to the comments in
Modules/CMakeExtraGeneratorDetermineCompilerMacrosAndIncludeDirs.cmake). It
doesn't seem to be related to providing any support for manipulating it in
a project. The only other place -stdlib seems to be mentioned is in the
setup of the macOS release build of CMake itself, which isn't relevant to
the discussion here.

If CMake were to offer direct support for -stdlib, it sounds like it would
be a clang-specific feature, so a clang-specific target property and/or
variable may be a way forward, analogous to the way it is done for Android.
Alternatively, maybe it could be done with generator expressions, but it
would be a bit verbose and harder to ensure the same -stdlib was used
consistently throughout if many targets were involved. But maybe just a
fairly simple check is good enough here, something like this (using
directory properties instead of variables):

if (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT ANDROID)
add_compile_options(-stdlib=libc++)
# Presumably need the above for linking too, maybe other options
missing as well
add_link_options(-stdlib=libc++)   # New command on CMake master, not
in 3.12 release
endif()

The linking comments above are in response to discussions in a recent issue
<https://gitlab.kitware.com/cmake/cmake/issues/18275> also related to the
-stdlib option. One down side of the above is no transitive dependency
details, something that a target property could achieve. I'll pause here
and see what others think.




>
> Just my two cents though.
>
> Best,
>
> Ian
>
>
>> Regarding your earlier comment:
>>
>> I'll explain a bit why I'm asking. I noticed that for code bases that
>>> work on Android plus other UNIX platforms, they unconditionally
>>> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
>>> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
>>> There's no way for me to "search" a platform to see if it is eligible
>>> for the libc++ flag, I simply have to either disable it completely or
>>> conditionally include it based on target platform and/or toolchain.
>>> None of these really address the root cause.
>>
>> If you are trying to control which STL to use for Android builds, C

Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?

[Craig Scott]

On Wed, Aug 22, 2018 at 7:18 AM, Robert Dailey 
wrote:

> On Tue, Aug 21, 2018 at 3:47 PM Craig Scott 
> wrote:
> > Excuse the brevity, but it sounds like you might be looking for the
> CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
> let me know why it isn't appropriate if so). See the following article for
> a more complete overview of this and related properties:
> >
> > https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/
>
> Unfortunately that's not the same. Extensions manage C++ language
> features and STL capabilities, but -stdlib is for selecting an STL
> implementation, AFAIK. Such as GNU STL and LLVM STL (which is libc++
> to clang).
>

Sorry, yes I misunderstood your problem. After a little digging, it seems
like you probably shouldn't be using the -stdlib option on Linux
<https://stackoverflow.com/a/50407611/1938798> anyway. FWIW, for Android,
the roadmap
<https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md> is
converging on a single STL implementation too.

Regarding your earlier comment:

I'll explain a bit why I'm asking. I noticed that for code bases that
> work on Android plus other UNIX platforms, they unconditionally
> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
> There's no way for me to "search" a platform to see if it is eligible
> for the libc++ flag, I simply have to either disable it completely or
> conditionally include it based on target platform and/or toolchain.
> None of these really address the root cause.

If you are trying to control which STL to use for Android builds,
CMake variables like CMAKE_ANDROID_STL_TYPE are probably the more
appropriate way to do that rather than hard-coding compiler flags.
This would also mean that non-Android builds won't be affected since
they would simply ignore that variable (and target properties it may
affect) and should then pick up the right STL implementation
automatically.The Android-specific variable would ideally be set in a
toolchain file rather than in the project itself.


-- 

Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

[cmake-developers] Quiet option for cmake

[Craig Scott]

A user has recently been asking
<https://gitlab.kitware.com/cmake/cmake/issues/18257> about reducing the
output coming from a FetchContent population when nothing needs to be done
(i.e. the content has already been populated). Because this is implemented
as a sub-build, you always see the following extra lines in the main
project's configure output (during the main configure, I'm not talking here
about the same messages at the end of the main configure):

-- Configuring done
-- Generating done
-- Build files have been written to: ...

I'm wondering if it makes sense to add support for a --quiet or --silent
option to cmake (and probably ccmake and cmake gui) which would skip these
messages? It would be an option question whether ordinary status messages
and messages which don't set any message mode should still be output for
such an option (maybe they would for --quiet but not for --silent). While
FetchContent is the motivation for this, perhaps other uses of CMake may
also find it useful as well.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] [CMake] libc++ usage in CMake with Clang?

[Craig Scott]

On Tue, Aug 21, 2018 at 11:41 PM, Robert Dailey 
wrote:

> I'll explain a bit why I'm asking. I noticed that for code bases that
> work on Android plus other UNIX platforms, they unconditionally
> specify `-stdlib=libc++`, however this doesn't work on Ubuntu by
> default, which uses gnu stl + gcc/clang. So  you get compiler errors.
> There's no way for me to "search" a platform to see if it is eligible
> for the libc++ flag, I simply have to either disable it completely or
> conditionally include it based on target platform and/or toolchain.
> None of these really address the root cause.
>
> I'm not even really sure what a find module for this would do... but
> typically find modules don't provide compiler flags, so I'm not sure
> if that's the right tool for the job. Would love to hear from the
> developers on this, so I've cross posted to the dev mailing list in
> this reply.
>


Excuse the brevity, but it sounds like you might be looking for the
CXX_EXTENSIONS target property (sorry if I've misunderstood your problem,
let me know why it isn't appropriate if so). See the following article for
a more complete overview of this and related properties:

https://crascit.com/2015/03/28/enabling-cxx11-in-cmake/





> On Mon, Aug 20, 2018 at 10:05 PM Thompson, KT  wrote:
> >
> > I'm also interested in the answer to Robert's question.  I've been using
> >
> >   set( CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -stdlib=libc++")
> >
> > but it seems like there should be a more elegant approach.
> >
> > -tk
> >
> > -Original Message-
> > From: CMake  On Behalf Of Robert Dailey
> > Sent: Monday, August 20, 2018 11:48 AM
> > To: CMake 
> > Subject: [CMake] libc++ usage in CMake with Clang?
> >
> > Is the only way to use libc++ to muck with compile flags? Or is there a
> proper find module for this or something? Is there a more CMake-esque way
> of specifying the STL library to use with the toolchain?
> > --
> >
> > 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-developers
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] CDash build groups email preferences not remaining filled

[Craig Scott]

This is the mailing list for CMake developers. Please send your query to
the CDash mailing list, which you can find here:

https://www.cdash.org/mailing-lists/



On Thu, Aug 16, 2018 at 5:52 AM, Vasquez, Justin 
wrote:

> Hi,
>
> I'm using CDash 2.4.0 to test my builds nightly. If I go to my project and
> navigate to Settings -> Groups -> Current BuildGroups, there are three tabs
> for Nightly, Continuous, and Experimental builds. When I click any of the
> email preferences (normal, summary, or no email) and save the changes, the
> buttons do not remain filled in when I refresh the page. This does not
> occur for the other button types which are check boxes nor for the text
> entry boxes. I queried the mysql database and can confirm that the email
> preferences are being set correctly. I would like the option to see what
> the current value of the email settings is just as I can see whether or not
> if "email committers" is checked off. Is there a way to edit the .php files
> to allow the email preferences buttons to remain filled?
>
> Justin
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

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

[Craig Scott]

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

-- 
Craig Scott
Melbourne, Australia
https://crascit.com

New book released: Professional CMake: A Practical Guide
<https://crascit.com/professional-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-developers

Re: [cmake-developers] target_link_libraries not callable from other directory scopes

[Craig Scott]

On Thu, Apr 26, 2018 at 4:22 AM, Patrick Stotko <
sto...@informatik.uni-bonn.de> wrote:

> Hi,
>
> this nice post (https://crascit.com/2016/01/3
> 1/enhanced-source-file-handling-with-target_sources/) mentions some
> modern usage of target_sources(), but also shows some discrepancy between
> target_link_libraries and the remaining target_* functions. In particlar,
> CMake does not allow linking to a target outside its creation scope whereas
> all the other ones do. There exists a workaround with include(), but it
> seems not the correct and clean way to handle this.
>
> So I think lifting this limitation would escepially help large-scale
> projects and improve modularization by handling third-party dependencies in
> the specific modules (as long as only this particular module needs it).
>
> So what is your experience regarding this linking restriction, especially
> in larger projects? I also opened an issue for this (see
> https://gitlab.kitware.com/cmake/cmake/issues/17943).
>
>
And from Brad's comment on that gitlab issue:

This limitation has been intentional since target_link_libraries was first
created long before the others. It is the oldest of the target_ commands.
The original justification is that we don't want to allow this because it
makes it very easy for non-local commands to drastically change the way a
target is built. That the newer target_ commands allow non-local targets
was an oversight.

Maybe the limitation could be lifted but I'd like to see a strong
justification and example use case.


Perhaps it was an oversight that newer target_... commands don't have the
same restriction as target_link_libraries(), but it is a very useful
oversight! As the linked blog article explains, it allows much better
modularity of the project. Extracting part of one of my comments on the
above-linked article:

For a real world example, consider a library or executable that has many
source files and where some functionality is optional and/or depends on the
availability of some external toolkit. Code related to such an optional
feature can be put in its own sub directory and conditionally included in
the library or executable. That sub directory can hold all the logic
related to that feature, including any external libraries that need to be
linked in. This is good modularisation since it localised the logic instead
of polluting the main CMakeLists.txt file.

It isn’t always possible or desirable to split out such an optional feature
to its own library (eg to ensure aspects of the implementation are not
revealed by exported symbol names or similar concerns). Thus, being able to
incorporate it directly into the main library or executable could be a
requirement. Being able to still isolate everything related to that feature
in its own sub directory can help keep things organised and easy to manage.


Being able to use add_subdirectory() instead of include() allows the
subdirectory to be more isolated, since any variables changed in the
subdirectory's scope won't affect the current scope. For new users,
add_subdirectory() also tends to feel more natural than include() and lead
to fewer errors. When using include(), you have to be very careful to use
CMAKE_CURRENT_LIST_DIR instead of CMAKE_CURRENT_SOURCE_DIR whenever you
need to construct an absolute path to something in the same (source)
directory, but new users often seem to not really know about
CMAKE_CURRENT_LIST_DIR. There's also no corresponding binary directory if
you use include(), unlike add_subdirectory() which nicely reproduces the
source directory structure in the build directory. Basically you can do
things with include() if you are careful, but add_subdirectory() is more
intuitive and more forgiving. The current restriction on
target_link_libraries() is the one hold-out for being able to make
subdirectories fully self-contained as far as building things goes.

Adding to the above quoted comment from the article, my experience on some
large projects has been that I can modularise optional parts of libraries
quite well using the various target_...() commands, but then I have to
duplicate some of the logic just because I still have to put the
target_link_libraries() call in the same directory as where the target is
defined. That's been a thorn in my side, because the modularity made
possible by target_sources() and the other target_...() commands have
otherwise allowed me to make the CMakeLists.txt files in each subdirectory
quite focused on just what that directory supplies. I found that using
include() instead of add_subdirectory() was confusing for some of our
users, so I tend to prefer to use add_subdirectory() and live with the
target_link_libraries() calls being leaked to the main directory, but I
would really love to avoid having to do that.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMa

Re: [cmake-developers] Surprising CMP0054 behavior

[Craig Scott]

On Mon, Mar 26, 2018 at 11:51 PM, Brad King <brad.k...@kitware.com> wrote:

> On 03/26/2018 08:07 AM, Craig Scott wrote:
> > Am I missing something, or is the following result surprising to others
> as well:
> >
> > set(somevar YES)
> > if ("somevar")
> > message("Get here if CMP0054 is OLD (seems okay)")
> > else()
> > message("Get here if CMP0054 is NEW (surprising?)")
> > endif()
> >
> > I would have thought that even with CMP0054 being NEW, the if condition
> would
> > still evaluate to true since it is going to test a non-empty string that
> > doesn't match any of the defined false constants.
>
> The observed behavior is consistent with the documentation.
>
> `if()` enumerates a set of true/false constants and says
> that if it is not one of these then it uses `if(<variable|string>)`.
> That is true only if it is a variable that is defined to a value that
> is not a false constant.  With CMP0054 NEW behavior, `if("string")`
> is always treated as the *string* variant which is never a variable
> defined to anything.
>

Okay, but the net effect of that logic is that for the expression
`if("${someVar}")`, if the value of `someVar` is neither a true nor false
constant, it ends up evaluating to false. This seems the opposite of what
it should be. Most languages generally take the path of if an expression
doesn't evaluate to known false values, the result is true (a la C's
"anything but 0 is considered true" approach). Even CMake's logic here
tries to be like that - it's how the unary if() behaves when given a
variable name rather than a quoted string (if the variable's value is not a
false constant, the result is true). The fact that it's the opposite when
given a string is the surprising part.

Probably the only practical path forward here is to clarify the docs, but
I'm still trying to wrap my head around how it could be explained without
ending up making it look like a confusing mess. At the very least though, I
think the docs for the CMP0054 policy needs an example specifically for
this unary if() scenario. It's just that the explanation that should go
with it is hard.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

[cmake-developers] Surprising CMP0054 behavior

[Craig Scott]

Am I missing something, or is the following result surprising to others as
well:

set(somevar YES)
if ("somevar")
message("Get here if CMP0054 is OLD (seems okay)")
else()
message("Get here if CMP0054 is NEW (surprising?)")
endif()

I would have thought that even with CMP0054 being NEW, the if condition
would still evaluate to true since it is going to test a non-empty string
that doesn't match any of the defined false constants.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

Re: [cmake-developers] INTERFACE IMPORTED example

[Craig Scott]

On Thu, Mar 22, 2018 at 10:37 PM, Brad King <brad.k...@kitware.com> wrote:

> On 03/21/2018 06:01 PM, Craig Scott wrote:
> > I swear I asked this a while back and there was an example given
>
> Maybe here:
>
> * https://gitlab.kitware.com/cmake/cmake/merge_requests/1581


Yes, that was it, thanks.




> > Does anyone know of a specific example scenario where an
> > INTERFACE IMPORTED library is the right choice over simply
> > INTERFACE or IMPORTED on its own?
>
> A non-INTERFACE imported target needs an IMPORTED_LOCATION,
> so an IMPORTED target wouldn't replace an INTERFACE IMPORTED
> target.
>
> A plain INTERFACE library and an IMPORTED INTERFACE library are
> nearly identical indeed, but the scope of the name differs.
>
> IMPORTED INTERFACE libraries mostly exist for install(EXPORT)
> to produce from an installed/exported INTERFACE library.
> They can't export as a normal INTERFACE library because
> imported targets have visibility isolated to the directory
> that imports them.
>


Okay. So the use case is inside a package's installed config file? i.e. if
a project wants to define an INTERFACE library to be provided as part of
its package, it should be defining an INTERFACE IMPORTED library? And
that's only needed because by convention, when someone does a
find_package(), any targets created by that are usually expected to be
imported targets with non-global scope, so an ordinary INTERFACE library is
not quite right because it has global scope (which CMake would allow, but
INTERFACE IMPORTED would be better). Following that through, the
combination INTERFACE IMPORTED GLOBAL is probably of little use now, since
either:

   - It doesn't need an IMPORTED_LOCATION, in which case a plain INTERFACE
   library is appropriate and arguably clearer/simpler.
   - It does need an imported location but since IMPORTED GLOBAL now
   supports setting interface properties, it could do the job and is also
   arguably clearer/simpler.

Only for pre-CMake 3.11 would INTERFACE IMPORTED GLOBAL be useful, since
IMPORTED GLOBAL didn't support setting interface properties before then.
And it would only be useful for the case where IMPORTED_LOCATION was being
set to point at a real library (otherwise just use INTERFACE on its own).

If there are any holes or errors in that, please let me know. Thanks.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

[cmake-developers] INTERFACE IMPORTED example

[Craig Scott]

I swear I asked this a while back and there was an example given, but I
have been unable to find it since. With changes done for CMake 3.11, I
think the question deserves asking again anyway.

Does anyone know of a specific example scenario where an INTERFACE IMPORTED
library is the right choice over simply INTERFACE or IMPORTED on its own?
I'm trying to understand what an "INTERFACE IMPORTED" library is primarily
used for and it seems others are equally confused. Now that some of the
restrictions around imported libraries have been relaxed
<https://gitlab.kitware.com/cmake/cmake/merge_requests/1264>, the
differences seem even less obvious. Anyone able to put forward a scenario?
If we can clarify this well, I'm happy to update the docs to make it clear
for everyone (okay, and so I can find it again in the future :P ).

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

[cmake-developers] Fwd: [CMake] Cmake Frameworks and Bitcode

[Craig Scott]

Forwarding to the developers list since it probably can best be answered
there.

-- Forwarded message --
From: Cameron Palmer 
Date: Tue, Mar 13, 2018 at 1:36 AM
Subject: [CMake] Cmake Frameworks and Bitcode
To: "cm...@cmake.org" 


So after a bit of hacking it seems that Cmake should provide something like:

CMAKE_OSX_BITCODE_ENABLE

Which would pass -fembed-bitcode to the compiler and linker and remove the
option in Darwin.cmake for -Wl,-headerpad_max_install_names in
CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS.

Does this sound like something that should be submitted as a patch?
-- 

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Non-failing BuildDepends has make errors

[Craig Scott]

See the end of this sample test output:

https://open.cdash.org/testDetails.php?test=604789995=5286961

The test is passing, but it ends with a build failure trying to build a
"clean" target that doesn't exist in the Makefile2 file (it *does* exist in
the top level Makefile in my local build when I was checking this test). Is
this behaviour expected? This only seems to happen in Makefile builds,
including nmake (platform doesn't seem to matter).

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

[cmake-developers] Android NEON and CMAKE_ANDROID_ARM_NEON docs

[Craig Scott]

According to the docs for CMAKE_ANDROID_ARM_NEON
<https://cmake.org/cmake/help/latest/variable/CMAKE_ANDROID_ARM_NEON.html>:

When Cross Compiling for Android and CMAKE_ANDROID_ARCH_ABI is set to
armeabi-v7a set CMAKE_ANDROID_ARM_NEON to ON to target ARM NEON devices.


But reading the Android ndk guide, it seems like NEON should also be
supported for arm64-v8a. From the Build Requirements section
<https://developer.android.com/ndk/guides/cpu-arm-neon.html#build>:

NEON support works with the armeabi-v7a and arm64-v8a ABIs.


Is this just a case of the CMake docs need to be updated?

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

[cmake-developers] XXX_FLAGS_INIT applied inconsistently

[Craig Scott]

I'm looking at the way the various XXX_FLAGS_INIT variables are handled
across the different compilers and platforms. These are set in many files
in the Modules/Compilers, Modules/Platforms and Modules directories. There
seems to be a couple of problems with what I'm seeing:


   - In most cases, the various files are appending rather than prepending
   to the existing contents of the XXX_FLAGS_INIT variables. This means any
   values developers provide cannot override the default ones because later
   flags usually take precedence over earlier ones.
   - Some platforms and compilers (e.g. IRIX, Windows-df, Generic-SDCC-C,
   OSF1, CSharp flags) unilaterally set XXX_FLAGS_INIT variables. This would
   discard any values a developer might set in a toolchain file, for example.

Since I don't know much about the history of all these, I was wondering if
there was any technical reason why the logic works this way? As things
stand, it can be difficult for developers to provide their own
XXX_FLAGS_INIT variables to customise things if they are overridden by the
defaults CMake provides.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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-developers

Re: [cmake-developers] Optionally disabling static lib dependencies with COMPILE_DEPENDS

[Craig Scott]

Perhaps keep an eye on the work going on in merge request 1524
<https://gitlab.kitware.com/cmake/cmake/merge_requests/1524>, which may
allow you to use object libraries in target_link_libraries(). Not sure if
it would cut the dependencies in the way you are seeking, but maybe take a
look and see.

On Fri, Jan 5, 2018 at 8:08 PM, John Wordsworth <johnwordswo...@gmail.com>
wrote:

> First of all - thanks for the suggestions. I intend to look into ccache
> for our Linux builds in the future and there are some useful tips here for
> me to look into. I wasn't aware of clcache and it looks very interesting,
> especially combined with network sharing.
>
> I realise I wasn't very clear in my previous explanation. Hopefully this
> paints a better picture;
>
> - We have 40 or so developers spread across Visual Studio 2015 (MSBuild -
> Windows), Xcode (macOS) and Make/Clang (Linux). 80% use Windows.
> - We have a core set of libs in use by a number of projects (~30 static
> libs and ~10 different projects), but the projects mix and match which libs
> they use - merging the static libs (beyond a few of them) isn't something
> we want to do.
> - I have recently been revising our CMake structure and have boiled it
> down to a fairly simple "add_library(x), target_link_libraries(x,
> default_compile_settings, dependencies)" which means compile settings,
> include directories and macros propagate through the libs nicely.
> - We sometimes want to build and use certain libs as shared libs instead
> of static libs.
>
> With regards to the COMPILE_DEPENDS feature that I have mocked up and
> started testing with our team;
>
> - If and only if COMPILE_DEPENDS is set for a STATIC library, then when
> building the target dependencies for that library, it uses the list of
> provided targets instead of those that would have been inferred from
> previous calls to "target_link_libraries" or "add_dependencies".
>
> The reality is, the libs which are being built statically can nearly all
> build in parallel with only one or two "real" dependencies. I understand
> that our case is rather specific, but having implemented "COMPILE_DEPENDS"
> and written ~10 lines of CMake in our project (hard coding the one or two
> actual build order dependencies and disabling the rest), our compile graph
> looks much nicer and saves a significant amount of time building on a
> single machine (see https://www.johnwordsworth.com/temp/cmake_compile_
> depends.jpg). We see similar savings on macOS using Xcode but have not
> tested on Linux yet. When we allow Incredibuild to distribute building of
> compilation units across 15-20 agents, the proportional build time drops
> more dramatically between the two (the same project goes from ~2.6mins ->
> ~1.6mins).
>
> I understand that just "hard overriding" the target dependencies is a bit
> messy, but I'd also be happy to explore other ways I could add a similar
> feature to CMake if there is a potentially better way to do this. What I am
> ideally looking for in a solution is that I can continue to propagate
> include directories / compile settings / preprocessor macros through the
> chain of libs and that it improves building static libs in parallel across
> all our build systems (MSVC / XCode / make). Ideally, I wouldn't have to
> restructure my CMake project too much either - as the draft I have for our
> new structure feels super clean now and refactoring it just to remove build
> order dependencies would be shame. If there are any alternative ideas for
> how to implement this, I'd love to discuss. I'm no CMake expert, but maybe
> if we could use "target_link_libraries" with OBJECT libraries to grab
> compile settings, or perhaps I could look into a mechanism for not adding
> build order dependencies on VS2015/Xcode if there is no need too?
>
> Thanks again for the feedback and discussion so far.
>
> // John W
>
> On Thu, Jan 4, 2018 at 12:16 PM, Eric Noulard <eric.noul...@gmail.com>
> wrote:
>
>>
>> 2018-01-04 10:48 GMT+01:00 Craig Scott <craig.sc...@crascit.com>:
>>
>>>
>>>
>>> On Thu, Jan 4, 2018 at 8:27 AM, John Wordsworth <j...@johnwordsworth.com
>>> > wrote:
>>>
>>>> I have recently been reviewing ways to improve build times for our
>>>> project, which is comprised of a number of static libraries. I stumbled
>>>> across this post on the CMake tracker from 2012/13 (
>>>> https://cmake.org/Bug/view.php?id=13799). It suggests adding a
>>>> COMPILE_DEPENDS target property to to explicitly set dependencies for
>>>> STATIC libraries instead of always using all linked librarie

Re: [cmake-developers] Optionally disabling static lib dependencies with COMPILE_DEPENDS

[Craig Scott]

On Thu, Jan 4, 2018 at 8:27 AM, John Wordsworth <j...@johnwordsworth.com>
wrote:

> I have recently been reviewing ways to improve build times for our
> project, which is comprised of a number of static libraries. I stumbled
> across this post on the CMake tracker from 2012/13 (
> https://cmake.org/Bug/view.php?id=13799). It suggests adding a
> COMPILE_DEPENDS target property to to explicitly set dependencies for
> STATIC libraries instead of always using all linked libraries as
> build-order dependencies.
>
> Having done a draft implementation in a local CMake repository it has
> shaved off  20% of our 120s build time. I expect the savings to be much
> more dramatic when I test with Incredibuild (approximately 50% based on
> tests done previously from just deleting dependencies manually in Visual
> Studio).
>
> I don’t really want to refactor our code to use “OBJECT” libraries as the
> inability to link with other targets means that propagating compile options
> / include directories etc down the chain of linked libs becomes painful.
> This method allows me to switch between static and shared libs using a
> config option and none of my CMake scripts need to change.
>

There's a couple more choices here. If your project consists of lots of
small (static) libraries, consider whether you can combine some of them to
result in a smaller number of larger libraries. This isn't always a gain,
but in terms of ability to compile sources in parallel, it will often lead
to more efficient builds. You just need to be careful you don't end up with
so many objects being combined into one library that you start to hit max
open file limits during linking/archiving (something I've hit on multiple
platforms lately, so it's not just a hypothetical example). Use of
target_sources() can be quite helpful if you want to try out this path (you
may find this article
<https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/>
helpful).

Another choice is to go in the opposite direction and take advantage of the
optimisation made for the Ninja generator (if that's a choice open to you)
that was introduced in CMake 3.9.0
<https://gitlab.kitware.com/cmake/cmake/merge_requests/430> where if no
custom commands exist on a target A, then compilation steps of another
target B linking to A are allowed to proceed without waiting for A's link
step to complete. Only B's link step will depend on A's link step. In your
project, if you have custom commands, see if you can split up that target
into just those sources that need the results of the custom command and
another target that doesn't. The latter will then be able to compile
earlier, so fewer sources have to wait for earlier linking steps. This
might be hard to do, it really depends on how your project is structured.

Both of the above choices allow you to retain the automatic propagation of
compile options, include directories, etc. and to switch between
shared/static easily, but the latter is specific to the Ninja generator and
may not be an acceptable change for you.



>
> Anyway, I was wondering whether there was any interest in me pushing my
> solution back to Git / submitting a Pull request so that it might be merged
> in at some point. If there is - any advice on any gotchas I might watch for
> instead of just adding some fairly simple code to
> cmComputeTargetDepends.cxx would be gratefully received - especially as
> this is my first time poking around in CMake code.
>

The existing behaviour is conservative and any change would have to also be
conservative, meaning that it must not introduce any possibility of
breaking existing projects. If I'm understanding your proposed feature
correctly, it sounds like you want to relax the build-order dependencies by
default when a COMPILE_DEPENDS target property is defined. Basically, if
COMPILE_DEPENDS is defined, you are taking over responsibility for the
build-order dependencies. This would be something I'd usually discourage
projects from doing because such manual dependencies would be a prime
candidate for not being kept up to date as a project evolves, leading to
subtle, hard-to-trace build errors. Some judicious project restructuring
can normally give a pretty efficient parallel build without having to
resort to such measures, so I'm wary of adding a feature like this (though
I can understand the desire for it).

In my experience, you can get some considerable speedups using tools like
ccache (and its equivalents for other platforms/compilers). These obviously
only help for subsequent builds of things that have been built previously,
but for everyday development where you switch between branches or for CI
servers doing lots of similar builds, the savings can be impressively big.

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

Powered by www.kitware.com

Please keep messages on-topic and ch

Re: [cmake-developers] Source file dependencies

[Craig Scott]

Have a look at the documentation for the OBJECT_DEPENDS source property
<https://cmake.org/cmake/help/latest/prop_sf/OBJECT_DEPENDS.html>, which
explains some options that may be relevant for your question.

On Fri, Dec 8, 2017 at 5:08 AM, Wouter Klouwen <wouter.klou...@youview.com>
wrote:

> Hi all,
>
> In trying to improve our build rules, one of the problems I encountered
> is that I effectively have some source files that cannot be compiled
> unless certain targets are run.
>
> I noticed that cmSourceFile has the AddDepend() method, which looks to
> do the kind of thing that I want to do.
> cmFlTKWrapUICommand and cmCPluginAPI are the only users of this, with
> there being no way of setting this from a CMakeLists.txt.
> The former seems to do exactly the kind of think that I need, which is
> to set up some code generation.
>
> It would be nice if I could add items to this list, perhaps through
> setting a property on the source files themselves, e.g this rather
> contrived short example:
>
> add_custom_command(OUTPUT bar.h COMMAND touch bar.h)
> add_custom_target(bar DEPENDS generate_bar bar.h)
> set_source_files_properties(foo.cpp PROPERTIES DEPENDS bar)
>
> Is this a bad idea? Would there be a better way?
>
> Thanks,
> W
> This transmission contains information that may be confidential and
> contain personal views which are not necessarily those of YouView TV Ltd.
> YouView TV Ltd (Co No:7308805) is a limited liability company registered in
> England and Wales with its registered address at YouView TV Ltd, 3rd Floor,
> 10 Lower Thames Street, London, EC3R 6YT. For details see our web site at
> http://www.youview.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:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] CMAKE architecture generator expression

[Craig Scott]

On Mon, Nov 6, 2017 at 4:12 AM, llvm 999 <llvm@outlook.com> wrote:

>
>
> Can anyone tell me the most appropriate generator expression to obtain the
> x32 vs x64 build info regardless of platform (windows or Linux)?
>
>
>
> I would like to place some static libs into certain output folders based
> on whether I am building for a x32 or x64 architecture.
>

Assuming you just want to differentiate between 32- and 64-bit builds,
something like the following should point you in the right direction:

$<$<EQUAL:4,${CMAKE_SIZEOF_VOID_P}>:...># 32-bit build
$<$<EQUAL:8,${CMAKE_SIZEOF_VOID_P}>:...># 64-bit build


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] iOS: direction to official support and questions

[Craig Scott]

On Thu, Sep 28, 2017 at 7:40 AM, Brad King <brad.k...@kitware.com> wrote:

> On 09/27/2017 08:18 AM, Raffi Enficiaud wrote:
> > For cross-compiling a project on iOS or iOS simulator, and since those 2
> > platforms are still Darwin, I believe that:
> >
> > * from a user perspective:
> >* CMAKE_SYSTEM_NAME should be set to "Darwin"
> >* CMAKE_SYSTEM_VERSION should be set to iOS or iOS-simulator,
> > possibly with a version (like "Mac OSX 10.2" in Darwin.cmake)
>
> Although macOS is based on Darwin, it has historically been a mistake
> to make CMAKE_SYSTEM_NAME "Darwin".  macOS and iOS are different
> enough that they each should have their own platform names/modules.
> Also, CMAKE_SYSTEM_VERSION should always be a number.
>
> > However, I just notice the existence of
> > "Modules/Platform/Darwin-Initialize.cmake" that is setting several
> > variables. When is this file sourced? should be before
> > "Modules/Platform/Darwin.cmake" but I failed to see from where.
>
> See comments here:
>
>   https://gitlab.kitware.com/cmake/cmake/blob/v3.9.3/
> Source/cmGlobalGenerator.cxx#L333-372
>
> for how all those files are loaded.  `iOS*.cmake` modules would be
> appropriate for first-class iOS support.  Ideally it should work
> with just `-DCMAKE_SYSTEM_NAME=iOS` without a full toolchain file,
> if that is possible.
>
> > I see several problems with this file if I were to make it iOS aware.
> > For instance it contains variables that are checking for the version,
> > but based only on the macOS scheme.
>
> That's why CMAKE_SYSTEM_NAME should be distinct so we can use a totally
> separate set of modules.  I think that solves most of the other problems
> you raised.
>

(Starting on a tangent, coming back to the above at the end). Note also
that for iOS builds, you don't really want to go fiddling with
the CMAKE_FIND_ROOT_PATH_MODE_... variables, either in toolchain files or
in platform support files that come with CMake. You see this a lot in
toolchain examples online, but that's not really compatible with the way
Xcode allows you to switch between device and simulator builds. There's not
really any 100% satisfactory solution to this in CMake at the moment, as
Eric Wing has summarised rather well in a few recent emails to this list.
As a starting point, I'd recommend only trying to set the minimal things in
iOS platform files which give a successful build. The handling of
find_...() command search paths falls outside of that, in my view.

FWIW, I've been experimenting with this area quite a bit lately after it
became a topic of discussion on this list, in the issue tracker and in
merge requests. At the moment, a minimal toolchain file for iOS which gets
you about as far as you can go seems to be something like this:

set(CMAKE_MACOSX_BUNDLE YES)
if(NOT CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED NO)
endif()

set(CMAKE_OSX_SYSROOT iphoneos)


All but the last line should ideally be unnecessary, but that's the current
state of things at least. The above setting of CMAKE_OSX_SYSROOT works
because Xcode sees the SDK as iphoneos but recognises that there's an
associated simulator configuration. You can then switch the target platform
(device or simulator) at build time without re-running CMake. This is
highly desirable for iOS devs, so it raises the question of how to not
break that if we make CMAKE_SYSTEM_NAME rather than Darwin +
CMAKE_OSX_SYSROOT as the primary way to set up for iOS. Also keep in mind
that, while most projects will probably just be happy to use the latest
installed SDK by default, it's technically possible to specify a specific
SDK version with an appropriate value in CMAKE_OSX_SYSROOT (e.g.
iphoneos9.3, or something like that, can't exactly recall off the top of my
head). If CMAKE_SYSTEM_NAME is taught to recognise iOS as distinct from
Darwin, we'd need to be very careful not to break existing projects that
assume the (fragile but still workable for some projects) method above.




-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Seeking feedback for new DownloadDependency module

[Craig Scott]

Devs,

Merge request 1306
<https://gitlab.kitware.com/cmake/cmake/merge_requests/1306> implements a
new module *DownloadDependency* and this email is to solicit feedback, with
a focus on the API the module presents. Brief summary follows so you can
get an idea if you're interested in the topic.

The new module provides three functions which together provide facilities
for downloading dependencies at configure time rather than at build time.
The main motivating case is to allow project dependencies to be downloaded
during configure so they can be brought into the build immediately via
add_subdirectory() or however the main project wants to make use of the
downloaded content (could also be things like certificates, assets, CMake
helper modules, etc.). The key feature is that you don't have to wait until
build time before the contents are available, so you can do things that
would not otherwise be possible with, for example, ExternalProject used in
the usual way. Another alternative, the file(DOWNLOAD) command, only
supports limited download methods, whereas DownloadProject supports all the
methods that ExternalProject_Add() supports (DownloadProject is implemented
in terms of ExternalProject_Add() via a sub-build executed via
execute_process()).

The module conveniently supports project hierarchies and gives parent
projects override control over any dependencies that child projects might
define. It also facilitates ensuring that a particular dependency is only
downloaded once if multiple child projects require it. No central
repository of build recipes is required, parent projects are in control of
any settings they wish to adjust before pulling in a child dependency via
add_subdirectory() or include() or whatever.

The module has been evolved in a real-world environment for the past 2
years on complex project hierarchies, with builds across Linux, Windows,
Mac and iOS. The module as presented in the merge request is a cleaned up
version of that. The three functions provided by the module are:


   - download_dependency_details()
   - download_dependency_state()
   - download_dependency()


See the documentation included in the merge request for an explanation of
each of these and the overall module. Examples are included in the docs.
Your feedback would be welcome.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] C++11 all features available?

[Craig Scott]

Probably just asking what a number of people are now thinking, but if we're
now requiring C++11 to build CMake, how long until we up the minimum Visual
Studio version from 2010 to at least 2013? Seems a bit optimistic to still
be trying to support 2010 as the minimum standard and also state C++11 as a
minimum.

On Wed, Aug 23, 2017 at 4:41 PM, Sebastian Holtermann <sebl...@xwmw.org>
wrote:

> > > > > it looks like C++11 is now a requirement for CMake itself.
> > > >
> > > > Yes.  We just merged this:
> > > >   https://gitlab.kitware.com/cmake/cmake/merge_requests/1132
> > > >
> > > > but you beat us to the announcement.
> > >
> > > I saw the MR last week and was delighted. The iterator type naming in
> > > `for`
> > > loops drove me mad.
> >
> > Feel free to use `auto`, but you will need to hold off range based for
> > loops.
>
> Okay, that's nice.
> Just to say, even without auto
>
>   for (const std::string& item : lst) {
> ...
>   }
>
> is easier to comprehend than
>
>   for (std::vector::const_iterator it = lst.begin();
>it != lst.end(); ++it) {
> const std::string& item = *it;
> ...
>   }
>
> which is as C++(98) as can be.
>
> > > > > But does this mean *all* the nice features from the std library
> can be
> > > > > used?
> > > >
> > > > Not all.  We're still limited by some of the older C++11 compilers.
> > > > We'll have to see how things go on nightly builds.  As limitations
> > > > are found they can be documented in `Help/dev/source.rst`.
> >
> > Please have a look at the nightly testers on
> > https://open.cdash.org/index.php?project=CMake and compare the feature
> > availability here: Please see
> > http://en.cppreference.com/w/cpp/compiler_support
> >
> > Currently CMake is still built with Visual Studio 2010, ie. MSVC 16.0.
> >
> > That means we should be able to use auto, nullptr, lambdas, std::array,
> > std::function, type traits, trailing return types, r-values, ...
>
> Very nice. C++11 was such a great improvement to the language.
> It's much more fun to work with. Even with the slightly limited
> feature set available in CMake.
>
> -Sebastian
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

On Fri, Aug 18, 2017 at 6:23 AM, Craig Scott <craig.sc...@crascit.com>
wrote:

>
>
> On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov <
> konstan...@podsvirov.pro> wrote:
>
>> Hello Clément Gregoire!
>>
>> 17.08.2017, 21:55, "Clément Gregoire" <lec...@gmail.com>:
>> > So the following worked for me:
>> >
>> > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder
>> >
>> > create a batch file named
>> >
>> > cmake-gui.bat
>> >
>> > with the following content
>> >
>> > @echo off
>> > start "" /B "%~dp0\gui\cmake-gui.exe" %*
>> >
>> > And modify qt.conf so that the plugin directory is correct :
>> >
>> > from  Plugins = ../plugins toPlugins = ../../plugins
>> >
>> > I'm not (yet) on the dev mailing list, so feel free to transfer the
>> solution there.
>>
>> Please review dev mailing list archive too:
>> http://public.kitware.com/pipermail/cmake-developers/2017-Au
>> gust/030228.html
>> (may be I forgot /B option)
>>
>
> Side note: really weird, but that email you've linked to never made it to
> my inbox (can't explain it, checked my trash and spam folders too), so I
> never saw your request to ask to test!
>
> In the past, one problem I've run into with using simple batch files as
> launcher scripts is that they can flash up a console window briefly before
> starting the real app. This can look suspicious and distracting to the
> user, so it is something to avoid. I think at one past employer we ended up
> using something like wscript instead, which allowed us to avoid that
> problem and it worked on all Windows versions without any extra software
> dependencies. Maybe we just didn't have good enough batch-file-fu, maybe
> things work differently now, I don't know. Been a number of years since
> I've looked at that specific problem. Some context, but only basic extra
> info:
>
> https://stackoverflow.com/a/9062764/1938798
>

Let me clarify the above (sorry, recalling more of the original problem we
had years back). The flashing up of a console window would occur if you ran
the launcher from somewhere other than an existing console window. For
example, if you double-clicked the launcher in Windows Explorer or via a
menu shortcut. In our case, we were using the script to set some
environment variables before launching the real app, so you always wanted
to use the launcher. In the discussion here about cmake-gui, you don't
really need that, you just want a way to forward the call to start the app
so you can avoid putting the real app and its DLLs on the PATH. So I guess
a batch file would be okay in this instance, since we would only be
expecting people to use it from a console window anyway (menu shortcuts,
etc. could still invoke the real cmake-gui app directly).


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

On Fri, Aug 18, 2017 at 5:05 AM, Konstantin Podsvirov <
konstan...@podsvirov.pro> wrote:

> Hello Clément Gregoire!
>
> 17.08.2017, 21:55, "Clément Gregoire" <lec...@gmail.com>:
> > So the following worked for me:
> >
> > move cmake-gui.exe, all dlls and qt.conf to a "cmkae/bin/gui" subfolder
> >
> > create a batch file named
> >
> > cmake-gui.bat
> >
> > with the following content
> >
> > @echo off
> > start "" /B "%~dp0\gui\cmake-gui.exe" %*
> >
> > And modify qt.conf so that the plugin directory is correct :
> >
> > from  Plugins = ../plugins toPlugins = ../../plugins
> >
> > I'm not (yet) on the dev mailing list, so feel free to transfer the
> solution there.
>
> Please review dev mailing list archive too:
> http://public.kitware.com/pipermail/cmake-developers/2017-
> August/030228.html
> (may be I forgot /B option)
>

Side note: really weird, but that email you've linked to never made it to
my inbox (can't explain it, checked my trash and spam folders too), so I
never saw your request to ask to test!

In the past, one problem I've run into with using simple batch files as
launcher scripts is that they can flash up a console window briefly before
starting the real app. This can look suspicious and distracting to the
user, so it is something to avoid. I think at one past employer we ended up
using something like wscript instead, which allowed us to avoid that
problem and it worked on all Windows versions without any extra software
dependencies. Maybe we just didn't have good enough batch-file-fu, maybe
things work differently now, I don't know. Been a number of years since
I've looked at that specific problem. Some context, but only basic extra
info:

https://stackoverflow.com/a/9062764/1938798

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] iOS: direction to official support and questions

[Craig Scott]

gt; The real problem seems to be when linking to system libraries, those that
> are under sysroot, and I cannot find a good answer to this.
>
> Example:
>
> Suppose in the toolchain file, we have something like this, where
> CMAKE_IOS_SDK_ROOT depends on the fact that we use the simulator or not:
>
> '''
> set(CMAKE_FIND_ROOT_PATH
> ${CMAKE_IOS_DEVELOPER_ROOT}
> ${CMAKE_IOS_SDK_ROOT}
> ${CMAKE_PREFIX_PATH}
> /some/other/path
> CACHE string  "iOS find search path root")
>
> # set up the default search directories for frameworks
> set (CMAKE_SYSTEM_FRAMEWORK_PATH
> ${CMAKE_IOS_SDK_ROOT}/System/Library/Frameworks
> ${CMAKE_IOS_SDK_ROOT}/System/Library/PrivateFrameworks
> ${CMAKE_IOS_SDK_ROOT}/Developer/Library/Frameworks
> )
> '''
>
> and later in our CMakeLists, we have eg.
>
> '''
> find_package(ZLIB REQUIRED)
> '''
>
> The selection of the SYSROOT is done then on the cmd line given to CMake,
> and set up once.
>
> The library that is found by ZLIB are related to CMAKE_IOS_SDK_ROOT, that
> is a constant in a build tree. Although Xcode can reroot the SYSROOT
> depending on the target device/arch (simulator/non-simulator).
>
> Even if later XCode is able to switch sysroots on the command line,
> depending on the target, the libraries we are linking to are constant, and
> not honoring the dynamically determined sysroot anymore.
>
> I believe this problem is going beyond XCode itself, as eg. Visual starts
> integrating more technologies (Xamarin, Android, Arduino, etc) to their
> IDE, and at some point the developers will want to use a simulator for
> those developments.
>
> My current concerns are about the design of CMake. Do you think the
> current design of CMake can possibly address this issue nicely, or the only
> possibilities are workarounds?
>
> * The fact that we have nice generator expressions can be used to
>   change the location of external libraries (and the overall link
>   interface) on the fly. I believe that might be used, we need to
>   intercept the IDE variable that encodes the current target, and
>   we might be able to use that variable jointly with the generator
>   expressions.
> * can we teach find_package/find_library to look for all
>   similar libraries in a set of sysroots? taking back the same
>   example of find_package(ZLIB), if I have, several sysroots:
>
>   CMAKE_FIND_ROOT_PATH_IOS = /sysroot/1
>   CMAKE_FIND_ROOT_PATH_IOS_SIMULATOR = /sysroot/2
>
>   and a new variable listing all the target platforms:
>
>   CMAKE_SYSROOT_NAMES = "IOS;IOS_SIMULATOR"
>
>   I can think of a mechanism that teaches find_library to look
>   for the same library in all of those SYSROOTS.
>
>
> Concerning the variable sent by the IDE and that might encode the current
> target, we have for instance this as a prelude to the compilation shell
> script:
>
> * for iPhone SDK
>   export PATH="/Applications/Xcode8.1.app/Contents/Developer/Platform
> s/iPhoneOS.platform/Developer/usr/bin:/Applications/Xcode8.
> 1.app/Contents/Developer/usr/bin:/usr/local/bin:/usr/bin:/
> bin:/usr/sbin:/sbin"
>
> * for iPhoneSimulatorSDK:
>   export PATH="/Applications/Xcode8.1.app/Contents/Developer/Platform
> s/iPhoneSimulator.platform/Developer/usr/bin:/Application
> s/Xcode8.1.app/Contents/Developer/usr/bin:/usr/local/
> bin:/usr/bin:/bin:/usr/sbin:/sbin"
>
> That is a poor solution for finding out for what current target platform
> we are compiling, and I hope it would be possible to retrieve the current
> ZLIB library we should link to based on $PATH. But I do not know if
> generator expressions are that flexible. This happens right before the
> compiler is executed, and cmake cannot be involved or called there. I am
> not even sure that we can modify the scripts that XCode generate for
> compilation.
>
> As you can see, those problems are not that Xcode or iOS specific, and
> maybe there is an elegant solution already in place, but I cannot find any.
>
> Thanks,
> Raffi
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Fwd: [CMake] cmake-gui on windows and qt5 dlls

[Craig Scott]

Devs,

It shouldn't be an issue having non-static Qt libs linked to cmake-gui, but
as reported on the CMake users mailing list, it can be a problem when the
directory cmake-gui is in is on the PATH. If CMake's bin directory appears
on the PATH, the Qt DLL's bundled with it can take precedence over other
applications' own Qt DLLs. The cmake and ccmake executables have a
reasonable case for being on the PATH, but cmake-gui is typically going to
be started via a desktop or menu icon and doesn't really need to be on the
PATH.

Rather than forcing static Qt libs to be used (I'm not aware of the reason
for the change from static to dynamic Qt libs), we could instead move
cmake-gui out of the bin directory so that it isn't in the same directory
as the cmake and ccmake executables. This top level directory should never
be added to the PATH, so it would resolve problems like the above. It is
not unusual for the main executable to be in the top level directory of an
installation rather than in a bin subdirectory. What do people think of
moving cmake-gui and the Qt DLL's up to the top level? This may just be for
Windows, other platforms could stay as they are now. Would obviously have
to adjust not just the install location but also any internal code that
tries to work out where other files are located relative to the cmake-gui
executable. Things like the qt.conf file would also probably need some
adjustment.

Thoughts?


-- Forwarded message --
From: Craig Scott <craig.sc...@crascit.com>
Date: Mon, Aug 14, 2017 at 7:47 PM
Subject: Re: [CMake] cmake-gui on windows and qt5 dlls
To: Christian Ehrlicher <ch.ehrlic...@gmx.de>
Cc: CMake <cm...@cmake.org>


This is a common problem, not just with CMake. I'm wondering if there's any
real need for cmake-gui to be on the PATH at all, since it will usually be
invoked by a desktop or menu icon. At the moment though, it is in the same
directory as the cmake and ccmake executables which have a much stronger
case for being on the PATH. There's a reasonable argument that cmake-gui
should be in a different directory, then it wouldn't be an issue if shared
Qt libs were used rather than static. I'll bring this up on the developer
mailing list and see what discussions yield.


On Mon, Aug 14, 2017 at 6:22 PM, Christian Ehrlicher <ch.ehrlic...@gmx.de>
wrote:

> Hi,
>
> I recently upgraded from cmake 3.3 to 3.9 on windows and got some problems
> during my build because it looks like the pre-compile binaries for windows
> are now shipping Qt5 - dlls instead static compile libs (since 3.5 afaics).
> The problem is, that I had the path to cmake *before* the path to my own
> Qt5 libaries. So during the build / run of my application, the wrong
> libraries were loaded and I got a symbol lookup error.
> Would it be possible to use the static Qt5 libs instead or maybe prefix
> the Qt5 libs shipped with cmake-gui somehow?
>
> Thx,
> Christian
>
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com



-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Linking Apple frameworks

[Craig Scott]

I'm exploring the behaviour of target_link_libraries() where the library to
be linked is an Apple framework. As part of this, I noticed that the
following does not work:

target_link_libraries(foo PRIVATE -framework AppKit)


This fails because the link command ends up with -framework -lAppKit
instead of -framework AppKit. Maybe that's expected, but then the following
DOES work:

target_link_libraries(foo PRIVATE "-framework AppKit")


Strangely, with the library quoted as above, the embedded space is not
escaped, leading to the (desirable but surprising) result -framework AppKit in
the linker command line (i.e. the space isn't escaped and the two words are
not quoted). *Which of these is the correct way (if either) and are both
behaving as expected?*

As extra context, a correct final linker command line can also be achieved
like this:

find_library(APPKIT_LIB AppKit)
target_link_libraries(foo PRIVATE ${APPKIT_LIB})


In this case, while APPKIT_LIB contains a full absolute path to the
framework, CMake manages to recognise it as a framework and shortens the
linker flags to just -framework AppKit. This is mentioned in the
find_library() docs:

If the library found is a framework, then  will be set to the full
> path to the framework /A.framework. When a full path to a
> framework is used as a library, CMake will use a -framework A, and a
> -F to link the framework to the target.
>

So it is clear why the find_library() approach works, but the behaviour of
directly specifying the framework without find_library() seems somewhat
surprising.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] PIE for executables

[Craig Scott]

There was recent(ish) work to resolve an issue with ensuring executables
are built with PIE enabled for Android, but it would appear that for other
platforms, CMake might not be providing the required set of linker flags,
missing out on -pie. The end result is that despite having
POSITION_INDEPENDENT_CODE set to ON, executables might still be getting
built with PIE not enabled.

Those who are familiar enough with the various compiler/linker/platform
details may want to take a look at the following issue which ties together
the information from a few related bug reports:

https://gitlab.kitware.com/cmake/cmake/issues/14983


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Built-in tag support for FindDoxygen

[Craig Scott]

On Thu, Jun 29, 2017 at 11:14 AM, Robert Dailey <rcdailey.li...@gmail.com>
wrote:

> Doxygen supports linking external documentation together:
> https://www.stack.nl/~dimitri/doxygen/manual/external.html
>
> Using doxygen_add_docs(), it doesn't provide built-in support for tag
> files. I'm thinking this would be beneficial since the way the
> function is designed encourages modular documentation. At least, I
> have my projects structured like this (targets):
>
> A
> A_doxygen
> B
> B_doxygen
> C
> C_doxygen
>
> I have 1 doxygen target per real library target. And each library has
> dependencies on others. When library C uses something from A, I want
> C_doxygen to link to the tagfile generated by A_doxygen.
>
> At the moment I'm accomplishing this by adding a target property to
> each real target to keep track of target dependencies. Example:
>
> add_library(C ...)
> target_link_libraries(C A)
> set_property(TARGET C PROPERTY TARGET_DEPENDENCIES A)
>
> When I'm building A_doxygen target (using doxygen_add_docs()), I
> specify DOXYGEN_GENERATE_TAGFILE. Then in C_doxygen, I specify
> DOXYGEN_TAGFILES to point to the one output by A_doxygen.
>
> I don't like keeping target properties to query the dependency tree,
> but this is the best I could come up with. Is there value in
> incorporating this into FindDoxygen.cmake? If so, I'd like to
> contribute it, if it's useful.
>

I think there's good potential for this idea. The doxygen_add_docs()
function could record the value of the DOXYGEN_GENERATE_TAGFILE variable in
a target property (I'd recommend using the same name as the variable). A
new DEPENDS option could be added to doxygen_add_docs() which would specify
other targets this one depends on. This would invoke add_dependencies() to
fulfil build ordering as usual, but it could also inspect the target
properties of the dependees and if the DOXYGEN_GENERATE_TAGFILE property is
set, then the DOXYGEN_TAGFILES variable could be augmented to pick up that
tag file somehow. You'd have to be careful how the paths were handled to
ensure they worked robustly, but conceptually at least I think this might
be possible and useful. Example usage would then be something like this:

# Populate DOXYGEN_GENERATE_TAGFILE if not already set,
# use existing contents otherwise. Either way, define a target property
# on foo which records the value.
doxygen_add_docs(foo)

# Does a similar thing as above for this target, but also picks up the
# tag file from foo as recorded in its target properties and augments

# the DOXYGEN_TAGFILES variable as appropriate.

doxygen_add_docs(bar DEPENDS foo)


You would need to be careful with how to handle contents of
DOXYGEN_GENERATE_TAGFILE and DOXYGEN_TAGFILES that the project might
already set. As a conservative measure, you might want to consider adding
an option NO_AUTO_TAGFILES or similar to disable any of this logic in case
a project does something complex and doxygen_add_docs() needs to be told to
leave it completely up to the project to handle. The doxygen_add_docs()
function was originally added with the intention of making it as easy as
possible for projects to use Doxygen with minimal extra configuration, so I
think having the auto tag handling enabled by default would probably be the
right call, as long as there's a way for projects to disable it if needed.


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Compile targets affected by changeset

[Craig Scott]

l
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>
>
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] CMake_TEST_XXX variables

[Craig Scott]

Anyone know what sets the various CMake_TEST_XXX variables that are checked
in Tests/CMakeLists.txt? I'm specifically wondering what might set
CMake_TEST_FindGTest, but I can't find any other reference to it. I'm
guessing it is only set on the CMake command line by CI builds or similar,
but getting that confirmed would be helpful.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] ;-list in docs

[Craig Scott]

It would seem that there are many cases where CMake documentation contains
the string ;-list which is not parsed as anything special and therefore
appears in the compiled documentation just like that. It looks like a
mistake, so I'm wondering whether there's a reason for it or if it is
something that could easily be cleaned up with a bit of search-and-replace?
I'm happy to do the merge request, just checking if I'm missing some reason
why it is there, given there are so many occurrences of it (about 37).

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Craig Scott]

On Fri, Jan 6, 2017 at 11:57 AM, Stephen Kelly <steve...@gmail.com> wrote:

> Craig Scott wrote:
>
> >> if you use add_subdirectory with top-level projects which don't
> >> explicitly do something like that, you're getting undefined , and
> >> generally unexpected behavior in many ways.
> >
> > This seems at odds with the CMake documentation for
> > cmake_minimum_required(). That documentation talks about calling
> > cmake_minimum_required() within a function as a valid case
>
> I don't know why using that command inside a function would be a good idea.
>
> What would you be trying to achieve with putting it in a function not near
> the top? Can you give an example?
>


That wasn't my point, I was only indicating that the documentation seems to
indicate it's a valid thing to do. I wouldn't argue that's it's a *useful*
thing to do. ;)



> > We have many projects which do exactly the scenario you mention above
> > where a project can be built standalone or added to another project via
> > add_subdirectory(). We have not found it necessary to test if a project
> is
> > top level or not before calling cmake_minimum_required().
>
> My comment should have been more-general in that the contained project
> should be designed to be 'inlined as a subdirectory' like that and it
> otherwise shouldn't be done.
>
> There are many pitfalls. I have encountered at least one pitfall resulting
> from cmake_minimum_required being unconditional which I don't remember now
> unfortunately. Perhaps the problem was my inexperience to understand
> messages I was seeing and what I expected from the code.
>
> Others include
>
> * conflicting target names
> * conflicting option()s, or option()s which shouldn't be exposed
> * modification of global or cache variables affecting the container project
> in unexpected ways such as modifying compile flags
> * possibly odd behavior if you have multiple include(CTest) or
> include(CPack) in different directories
> * projects which assume CMAKE_SOURCE_DIR is their top-level and use
> something like include($CMAKE_SOURCE_DIR}/cmake/MyPrivateMacros.cmake)
> * deliberate checks for top-level in a file include()d in multiple
> locations
> in the project.
>
> Sure, you can test things out when you add a new
>
>  add_subdirectory(random_github_clone)
>
> but just because it works (enough! - do any of them use CMAKE_SOURCE_DIR
> and
> it doesn't cause *visible* problems?) with all of the external projects
> you've tried so far doesn't mean you can expect it to work with any
> external
> project.
>
> For me, that's as close as you get to 'undefined behavior' in CMake code.
>
>
We use the approach mostly with projects under our control, so we can
address the various issues you mentioned such that projects are safe to use
in this way. Even for the 3rd party projects we use, we set the git tag to
a known sha and can work through any issues to get the behaviour we want
for that specific snapshot of their code in most cases. There are a few
tricks you can use to inject things into such projects without having to
edit them (e.g. fixing missing INTERFACE dependencies with the various
target_xxx commands and using the CMAKE_PROJECT_https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] COMPILE_FEATURES, Mac and non-Apple clang versions

[Craig Scott]

On Wed, Jan 4, 2017 at 11:43 AM, Stephen Kelly <steve...@gmail.com> wrote:

> René J.V. Bertin wrote:
>
> > The
> > issue was a project that requested an earlier CMake version
> > (2.8.something) further down.
>
> There should be no 'further down'. There should be exactly one use of
> cmake_minimum_required per buildsystem. If you are hitting this issue
> because you are cloning random repos and using add_subdirectory, you're
> essentially getting undefined behavior, unless the target repo is designed
> to let you do that.
>
> That is - some buildsystems check whether they are top-level and only then
> invoke cmake_minimum_required. Something like:
>
>  if (CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
># Building standalone
>cmake_minimum_required(VERSION 3.3)
>project(Dependency)
>  endif()
>
>  add_executable(etc)
>
>
>
> if you use add_subdirectory with top-level projects which don't explicitly
> do something like that, you're getting undefined , and generally unexpected
> behavior in many ways.
>

This seems at odds with the CMake documentation for
cmake_minimum_required(). That documentation talks about calling
cmake_minimum_required() within a function as a valid case, which is
obviously not going to be at the start of a top level CMakeLists.txt file.
I see no reason why having multiple calls to cmake_minimum_required()
shouldn't work. Yes, each one will alter the policy behaviour for that
scope and below, but assuming that's what the project wanted to enforce,
this should be fine.

We have many projects which do exactly the scenario you mention above where
a project can be built standalone or added to another project via
add_subdirectory(). We have not found it necessary to test if a project is
top level or not before calling cmake_minimum_required(). The behaviour is
well-defined and performs as per the documentation in regard to policies
and minimum CMake versions as far as we've observed. Can you point me/us at
documentation or code which shows why this should be considered undefined
behaviour? I'm particularly interested in this case since we use it
frequently in production.

Also, in case it is of interest, in a hierarchical project arrangement
where another project is brought in via add_subdirectory, the
CMAKE_POLICY_DEFAULT_CMP
<https://cmake.org/cmake/help/latest/variable/CMAKE_POLICY_DEFAULT_CMP.html>
variable
can be used to alter the default for a policy so that if that sub-project
specifies an older version in its cmake_minimum_required(), the
driving/main project can still influence its behaviour without requiring
changes to that sub-project. Not ideal, but I've had at least one
legitimate case where this was useful (dealing with warnings associated
with CMP0048 <https://cmake.org/cmake/help/latest/policy/CMP0048.html>).


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Specifying sources without file extensions

[Craig Scott]

I've come across some projects where the source files listed in their
add_executable() and add_library() commands do not have file extensions. It
seems that CMake still finds the sources by trying some set of file
suffixes. This is not documented behaviour, but it does show up in error
messages if you give those commands a file name for a non-existent source.
For example, if I specify a full filename which doesn't exist, I see an
error message similar to the following:

CMake Error at /somepath/CMakeLists.txt:10 (add_library):

  Cannot find source file:


../somethingThatDoesNotExist.h


  Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp

  .hxx .in .txx


So my question is whether specifying source file names without extensions
is a feature which is simply missing documentation or is it an undocumented
feature that projects are not supposed to use? Since there are error
messages like the above, it would seem that the latter would be a harder
position to justify.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Docs for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT

[Craig Scott]

There seems to be a number of references online to a variable
named CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT which is recommended for
checking if CMAKE_INSTALL_PREFIX has been overridden or not. This variable
is not mentioned in CMake's documentation, but some of those online
references claim it was recommended by CMake devs to use this variable. Is
it formally supported? If so, can documentation be added for it so that
users can have confidence that they are using a supported feature? Even
just something very simple would be enough to meet that need.

Some example references to this:

http://public.kitware.com/pipermail/cmake/2010-December/041135.html

http://stackoverflow.com/a/16076855/1938798


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] LINK_FLAGS and STATIC_LIBRARY_FLAGS target properties

[Craig Scott]

Looking at the latest CMake docs for the LINK_FLAGS and
STATIC_LIBRARY_FLAGS target properties, neither mentions support for
generator expressions. This seems to be at odds with other target
properties which are documented as having support for generator
expressions, particularly the compiler counterparts COMPILE_DEFINITIONS,
COMPILE_OPTIONS and INCLUDE_DIRECTORIES. Is it just a case of the linker
properties haven't had their documentation updated or do they not yet have
generator expression support?

The situation for the INTERFACE_LINK_LIBRARIES target property is also a
bit odd in that it's documentation doesn't mention support for generator
expressions, but that for LINK_LIBRARIES does. Again, is this just docs
being out of date or is the interface version of this property still
lacking generator expression support? It would seem odd that the
non-interface property supports them but the interface property doesn't.

For both cases above, if those properties which don't have documented
generator expression support indeed don't support them, are there plans to
add such support any time soon?

Sorry for all the questions, none of this is blocking me on anything, I'm
just wanting to clarify the situation to gain a better understanding of
what capabilities can be relied on to be available.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Current deficiencies of automoc

[Craig Scott]

Good background, just a minor correction:

On Sat, Oct 22, 2016 at 5:44 PM, Sascha Cunz <sas...@cunz-rad.com> wrote:

>
> The problem here is, that once a target is created in CMake, you can’t add
> any files to it. So this has to be done that way.
>

Not actually true, the target_sources()
<https://cmake.org/cmake/help/latest/command/target_sources.html> command
can do precisely that. The following article shows some reasons why this is
particularly useful:

https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Java_INCLUDE_DIRS not populated by FindJava.cmake

[Craig Scott]

Unless I'm missing something, it would seem that even though the
documentation says FindJava.cmake sets Java_INCLUDE_DIRS, I don't see
anything in that file or things it includes which try to set it. Is the
documentation out of date or is the FindJava.cmake implementation missing
some things? Or am I just blind and missed something obvious? ;)

In case anyone is wondering, the use case for me is when implementing a
SWIG custom command to generate java wrappers, the jni.h header needs to be
found by the generated sources.

Cheers

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] Generator options per-directory v. global

[Craig Scott]

I'm coming in half way to this discussion, so apologies if my comments
interspersed below are not so well related to the core topic of discussion.

On Thu, Oct 6, 2016 at 9:38 AM, Stephen Kelly <steve...@gmail.com> wrote:

> Brad King wrote:
>
> > The scoping doesn't
> > match the generator semantics exactly, but it is easy to use and
> > hasn't been a big problem.
>
> My mail is suggesting that it is a problem and is undesirable to maintain.
>
> Big is subjective, and there are not many complaints, because generally
> people don't try to set things like this per-directory (and if they did it
> would probably mostly do what they expect).
>
> The problems are
>
> 1) It is a behavior which is often not intended by the programmer.
> 2) It makes refactoring harder if such unintended behavior must be
> preserved.
> 3) It is unintuitive, because code such as
>
>  set(FOO ON)
>  project(p)
>  add_library(bar ...)
>  set(FOO OFF)
>
> looks like FOO is ON when defining the project and the target, but in
> reality it is only the value at the end of the directory that is consumed.
>

Consider the following example which perhaps better shows that this problem
may not be as uncommon as first thought:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -someOption")
add_library(foo ...)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -somethingElse")

I think most developers probably expect foo to not have the -somethingElse
option when it is compiled, but I believe it would have it. Given that it
is not unusual (but not necessarily wise) for projects to fiddle with
variables like CMAKE_CXX_FLAGS in subdirectories which could be brought in
via include() rather than add_subdirectory(), this behaviour of using the
variable's value at the end of the directory processing is likely a
surprise to many and probably already causes some head-scratching until
devs figure it out. Is the problem being discussed here relating to
CMAKE_CODELITE_USE_TARGETS
much different?

If I understand things correctly, directory *properties* don't typically
have this unexpected behaviour as their value at the time of defining the
targets is used, not at the end of that directory's processing. They serve
as defaults for target-specific properties at the point of the target being
defined. Not sure if that helps with the original topic of discussion here
though.



>
> Those are not problems users or contributors adding features encounter, so
> that might affect a perception of 'big'ness. These problems only bubble up
> during refactoring or under longer-term maintenance when the true semantics
> of the code become known.
>

Perhaps a bit more common than that, as the above example suggests.


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[cmake-developers] Use of C++11 in CMake's own source code

[Craig Scott]

Tried searching the archives for this but too many hits for the general
CMake feature supporting C++11. What's the current policy for use of C++11
in CMake's own source code? A cursory trip through some sources recently
suggested no C++11 features are being used, which I can understand if there
is the requirement to support building CMake on systems with compilers
which don't have C++11 support. I do, however, see some C++11 stuff in at
least one recent merge request, so I'm wondering what the current policy on
this is? I don't want to start a long philosophical discussion, I just want
to clarify the constraints on merge requests, etc.

-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

I've implemented the change to not run regular tests if they require a
fixture with a setup test that fails. The merge request has been reopened
and updated. Hopefully this can go through before the feature freeze for
3.7. ;)


On Mon, Sep 12, 2016 at 11:09 PM, Brad King <brad.k...@kitware.com> wrote:

> On 09/10/2016 11:34 AM, Craig Scott wrote:
> > have a crack at adding the required functionality to my fixtures branch
> > so that regular tests are skipped if setup tests fail
> [snip]
> > limit the new functionality just to fixtures where the required
> > behaviour is well defined.
>
> Sounds good to me.  Please re-open and extend the associated MR when
> ready.
>
> Thanks,
> -Brad
>
>


-- 
Craig Scott
Melbourne, Australia
https://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

On Fri, Sep 9, 2016 at 5:14 AM, Daniel Pfeifer <dan...@pfeifer-mail.de>
wrote:

> On Thu, Sep 8, 2016 at 5:52 PM, Brad King <brad.k...@kitware.com> wrote:
> > I think if we introduce the notion of tests requiring other tests
> > then a new model of test selection and enablement needs to be
> > designed.  Some kind of test DAG could be defined with various
> > roots and subgraphs being selectable an causing all reachable
> > tests to be included.
>
> This could be expanded even further. If "tests requiring other tests"
> is generalized to "tests requiring X", wouldn't this allow incremental
> testing?  Say you change one file in your project. You rebuild only
> the parts of the project that are affected by this change. Then you
> rerun only the tests that are affected by the change. This really has
> to be carefully thought out.
>

Interesting idea, but yes potentially a big body of work. That said, the
fixtures implementation up for review already gets you most of the way
there I think. One could potentially define a fixture that covers the tests
for functionality a developer is working on. A test is able to require
multiple fixtures, so developers could define fixtures to whatever
granularity they wanted. We could add option(s) to the ctest command line
which allow selection of tests based on fixture names in the same way we
currently do with labels and test names. This would allow developers to run
just the set of tests related to a particular functionality. One could
argue that labels already get you most of the way there now too, but since
fixtures would come with clean handing of setup/cleanup dependencies, they
may be more useful to developers. They also feel a bit closer to the
implementation than what labels are likely to cover and so fixtures might
be a better fit for the scenario you mentioned. I'd also be skeptical
whether we could make it easy/convenient/robust for CMake to work out which
tests to re-run based on which files had to be rebuilt. Asking developers
to pick which fixture(s) to retest instead might be a good compromise due
to the simplicity of both use and implementation.

Even aside from whether the above would satisfy the proposed scenario,
maybe it's worth considering adding test selection based on fixture names
regardless. I think this probably should be a separate branch that follows
from the current one though so it doesn't turn into a monster of a merge.
;) I'd be happy to look at that idea once the current branch is done and
in, since I have a concrete use case driving me to get that one completed
first.

-- 
Craig Scott
Melbourne, Australia
http://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

On Thu, Sep 8, 2016 at 11:52 PM, Brad King <brad.k...@kitware.com> wrote:

> On 09/08/2016 10:15 AM, Craig Scott wrote:
> > adding a DEPENDS_ON_SUCCESS test property or something similar
> > which would implement the perhaps more intuitive behaviour of not
> > running dependent tests when a dependee fails. If that was done,
> > then implementing the "don't run fixture tests if any fixture
> > setup fails" logic would be trivial.
>
> The semantics of this will have to be carefully though out, in
> particular with respect to enabling test dependencies.  Right now
> ctest arguments like -E can exclude tests.  What if those are
> dependencies of included tests?
>
> I think if we introduce the notion of tests requiring other tests
> then a new model of test selection and enablement needs to be
> designed.  Some kind of test DAG could be defined with various
> roots and subgraphs being selectable an causing all reachable
> tests to be included.
>

While I can see potential merit, I'd be reluctant to go so far as adding
the complexity of a test DAG. One of the attractive things about the
current functionality is its simplicity. It's relatively easy for new
developers to learn how to use it and I'm keen to preserve that as much as
possible, since it helps with adoption of CTest and CMake in general.

Indeed, in the more general case, if we added a DEPENDS_ON_SUCCESS test
property then we would have to work through how to handle situations where
dependee tests were not in the initial test set to be executed. I think
this might be less clear cut than I initially thought, so I'm tending to
back away from this as a general feature now. For the case of test fixtures
though, the semantics are very clear and would be well defined, since one
of the primary purposes of fixtures is to bring in setup and cleanup tests
which might not have been part of the initial test set. If no-one objects,
I'll have a crack at adding the required functionality to my fixtures
branch so that regular tests are skipped if setup tests fail (i.e. as per
the latest set of requirements that were proposed on this list a few days
ago) and I'll do so without adding a new DEPENDS_ON_SUCCESS test property.
That will limit the new functionality just to fixtures where the required
behaviour is well defined.

-- 
Craig Scott
Melbourne, Australia
http://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

I should also point out that another reason for not implementing the
"skipping tests if the setup fails logic" relates to the current behaviour
of DEPENDS. At the moment, if test B depends on test A, test B still
executes if test A fails. This is both useful and unexpected at the same
time. It is unexpected because I'd initially have thought of DEPENDS as
meaning I can't run test B if test A fails, after all, B depends on A which
I'd interpret to mean if A fails, then something B requires isn't working.
Conversely, this is also useful because until now, DEPENDS was the only way
to get cleanup functionality to run after other tests, and if those other
tests fail, we still want the cleanup to occur.

Current behaviour of DEPENDS can't change because there would be too much
out there in the wild relying on the existing behaviour. I'm wondering if
there's merit in adding a DEPENDS_ON_SUCCESS test property or something
similar which would implement the perhaps more intuitive behaviour of not
running dependent tests when a dependee fails. If that was done, then
implementing the "don't run fixture tests if any fixture setup fails" logic
would be trivial.


On Thu, Sep 8, 2016 at 6:08 PM, Craig Scott <craig.sc...@crascit.com> wrote:

> Merge request implementing this feature is now up for review here:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/88
>
> I ended up going with FIXTURE_... test property names rather than
> GROUP_... since it seemed more specific. I have not implemented the logic
> for skipping regular tests if any of a fixture's setup tests fail as that
> would require more change than I wanted to bite off for this initial
> implementation. If it is really required, I guess it could be done, but my
> primary concern first is not to introduce new bugs. ;)
>
>
>
> On Thu, Sep 1, 2016 at 9:17 AM, Craig Scott <craig.sc...@crascit.com>
> wrote:
>
>> Actually, we can't really re-use the RESOURCE_LOCK for the proposed
>> RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force
>> all the tests using that resource to be serialised. So yes, a separate
>> GROUP or something similar would seem to be needed. Let me amend my earlier
>> proposal (which is an evolution of Ben's) to something like this:
>>
>>
>> add_test(NAME setup-foo ...)
>> set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo)
>>
>> add_test(NAME cleanup-foo ...)
>> set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo)
>>
>> add_test(NAME use-foo ...)
>> set_tests_properties(use-foo PROPERTIES GROUP foo)
>>
>>
>> The logic would be as follows:
>>
>>- Any test cases with a GROUP_SETUP property for a group will be run
>>before any test cases with GROUP or GROUP_CLEANUP for that same group. The
>>order of these setup test cases can be controlled with the existing 
>> DEPENDS
>>test property.
>>- If any of the group's setup test cases fail, all other test cases
>>for that group will be skipped. All cleanup test cases for the group
>>probably should still be run though (it could be hard to try to work out
>>which cleanup tests should run, so maybe conservatively just run all of
>>them).
>>- If all setup test cases passed, then run all test cases for that
>>group. Regardless of the success or failure of these test cases, once they
>>are all completed, run all the cleanup test cases associated with the 
>> group.
>>- Ordering of cleanup test cases can again be controlled with the
>>existing DEPENDS test property.
>>
>> What the above buys us is that CTest then knows definitively that if it
>> is asked to run a test case from a particular group, it must also run the
>> setup and cleanup test cases associated with that group, regardless of
>> whether those setup/cleanup test cases are in the set of test cases CTest
>> was originally asked to run. At the moment, CTest could theoretically do
>> that for the setup steps based on DEPENDS functionality, but not the
>> cleanup. The above proposal is very clear about the nature of the
>> dependency and gives the symmetry of both setup and cleanup behaviour.
>>
>> I'm not tied to the terminology of "GROUP" for tying a set of test cases
>> to their setup/cleanup tasks, so I'm happy to consider alternatives. I'm
>> also wondering whether simply GROUP for a test property is too generic for
>> the test cases that require the setup/cleanup (as opposed to the test cases
>> that ARE the setup/cleanup).
>>
>>
>> On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott <craig.sc...@crascit.com>
>> wrote:
>>
>

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

Merge request implementing this feature is now up for review here:

https://gitlab.kitware.com/cmake/cmake/merge_requests/88

I ended up going with FIXTURE_... test property names rather than GROUP_...
since it seemed more specific. I have not implemented the logic for
skipping regular tests if any of a fixture's setup tests fail as that would
require more change than I wanted to bite off for this initial
implementation. If it is really required, I guess it could be done, but my
primary concern first is not to introduce new bugs. ;)



On Thu, Sep 1, 2016 at 9:17 AM, Craig Scott <craig.sc...@crascit.com> wrote:

> Actually, we can't really re-use the RESOURCE_LOCK for the proposed
> RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force
> all the tests using that resource to be serialised. So yes, a separate
> GROUP or something similar would seem to be needed. Let me amend my earlier
> proposal (which is an evolution of Ben's) to something like this:
>
>
> add_test(NAME setup-foo ...)
> set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo)
>
> add_test(NAME cleanup-foo ...)
> set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo)
>
> add_test(NAME use-foo ...)
> set_tests_properties(use-foo PROPERTIES GROUP foo)
>
>
> The logic would be as follows:
>
>- Any test cases with a GROUP_SETUP property for a group will be run
>before any test cases with GROUP or GROUP_CLEANUP for that same group. The
>order of these setup test cases can be controlled with the existing DEPENDS
>test property.
>- If any of the group's setup test cases fail, all other test cases
>for that group will be skipped. All cleanup test cases for the group
>probably should still be run though (it could be hard to try to work out
>which cleanup tests should run, so maybe conservatively just run all of
>them).
>- If all setup test cases passed, then run all test cases for that
>group. Regardless of the success or failure of these test cases, once they
>are all completed, run all the cleanup test cases associated with the 
> group.
>- Ordering of cleanup test cases can again be controlled with the
>existing DEPENDS test property.
>
> What the above buys us is that CTest then knows definitively that if it is
> asked to run a test case from a particular group, it must also run the
> setup and cleanup test cases associated with that group, regardless of
> whether those setup/cleanup test cases are in the set of test cases CTest
> was originally asked to run. At the moment, CTest could theoretically do
> that for the setup steps based on DEPENDS functionality, but not the
> cleanup. The above proposal is very clear about the nature of the
> dependency and gives the symmetry of both setup and cleanup behaviour.
>
> I'm not tied to the terminology of "GROUP" for tying a set of test cases
> to their setup/cleanup tasks, so I'm happy to consider alternatives. I'm
> also wondering whether simply GROUP for a test property is too generic for
> the test cases that require the setup/cleanup (as opposed to the test cases
> that ARE the setup/cleanup).
>
>
> On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott <craig.sc...@crascit.com>
> wrote:
>
>> In my original thinking, I was of the view that if a setup/cleanup step
>> needed to be executed for each test rather than for the overall test run as
>> a whole, then perhaps the test itself should handle that rather than CMake.
>> The existing RESOURCE_LOCK functionality could then be used to prevent
>> multiple tests from running concurrently if they would interfere with each
>> other. Existing test frameworks like GoogleTest and Boost Test already have
>> good support for test fixtures which make doing this per-test setup/cleanup
>> easy. The problem I want to solve is where a group of tests share a common
>> (set of) setup/cleanup steps and CMake knows to run them when asked to run
>> any test cases that require them. The specific problem motivating this work
>> was running ctest --rerun-failed, where we need CMake to add in any
>> setup/cleanup steps required by any of the tests that will be rerun. With
>> that in mind, see further comments interspersed below.
>>
>>
>> On Fri, Aug 26, 2016 at 12:08 AM, Ben Boeckel <ben.boec...@kitware.com>
>> wrote:
>>
>>> On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote:
>>> > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott:
>>> > > So how would you want the feature to work? I'd suggest an initial
>>> set of
>>> > > requirements something like the following:
>>> > >
>>> > >

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

Actually, we can't really re-use the RESOURCE_LOCK for the proposed
RESOURCE_SETUP and RESOURCE_CLEANUP functionality since that would force
all the tests using that resource to be serialised. So yes, a separate
GROUP or something similar would seem to be needed. Let me amend my earlier
proposal (which is an evolution of Ben's) to something like this:


add_test(NAME setup-foo ...)
set_tests_properties(setup-foo PROPERTIES GROUP_SETUP foo)

add_test(NAME cleanup-foo ...)
set_tests_properties(cleanup-foo PROPERTIES GROUP_CLEANUP foo)

add_test(NAME use-foo ...)
set_tests_properties(use-foo PROPERTIES GROUP foo)


The logic would be as follows:

   - Any test cases with a GROUP_SETUP property for a group will be run
   before any test cases with GROUP or GROUP_CLEANUP for that same group. The
   order of these setup test cases can be controlled with the existing DEPENDS
   test property.
   - If any of the group's setup test cases fail, all other test cases for
   that group will be skipped. All cleanup test cases for the group probably
   should still be run though (it could be hard to try to work out which
   cleanup tests should run, so maybe conservatively just run all of them).
   - If all setup test cases passed, then run all test cases for that
   group. Regardless of the success or failure of these test cases, once they
   are all completed, run all the cleanup test cases associated with the group.
   - Ordering of cleanup test cases can again be controlled with the
   existing DEPENDS test property.

What the above buys us is that CTest then knows definitively that if it is
asked to run a test case from a particular group, it must also run the
setup and cleanup test cases associated with that group, regardless of
whether those setup/cleanup test cases are in the set of test cases CTest
was originally asked to run. At the moment, CTest could theoretically do
that for the setup steps based on DEPENDS functionality, but not the
cleanup. The above proposal is very clear about the nature of the
dependency and gives the symmetry of both setup and cleanup behaviour.

I'm not tied to the terminology of "GROUP" for tying a set of test cases to
their setup/cleanup tasks, so I'm happy to consider alternatives. I'm also
wondering whether simply GROUP for a test property is too generic for the
test cases that require the setup/cleanup (as opposed to the test cases
that ARE the setup/cleanup).


On Thu, Sep 1, 2016 at 10:50 AM, Craig Scott <craig.sc...@crascit.com>
wrote:

> In my original thinking, I was of the view that if a setup/cleanup step
> needed to be executed for each test rather than for the overall test run as
> a whole, then perhaps the test itself should handle that rather than CMake.
> The existing RESOURCE_LOCK functionality could then be used to prevent
> multiple tests from running concurrently if they would interfere with each
> other. Existing test frameworks like GoogleTest and Boost Test already have
> good support for test fixtures which make doing this per-test setup/cleanup
> easy. The problem I want to solve is where a group of tests share a common
> (set of) setup/cleanup steps and CMake knows to run them when asked to run
> any test cases that require them. The specific problem motivating this work
> was running ctest --rerun-failed, where we need CMake to add in any
> setup/cleanup steps required by any of the tests that will be rerun. With
> that in mind, see further comments interspersed below.
>
>
> On Fri, Aug 26, 2016 at 12:08 AM, Ben Boeckel <ben.boec...@kitware.com>
> wrote:
>
>> On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote:
>> > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott:
>> > > So how would you want the feature to work? I'd suggest an initial set
>> of
>> > > requirements something like the following:
>> > >
>> > >- Need to support the ability to define multiple setup and/or tear
>> down
>> > >tasks.
>> > >- It should be possible to specify dependencies between setup
>> tasks and
>> > >between tear down tasks.
>> > >- Individual tests need to be able to indicate which setup and/or
>> tear
>> > >down tasks they require, similar to the way DEPENDS is used to
>> specify
>> > >dependencies between test cases.
>> > >- When using ctest --rerun-failed, ctest should automatically
>> invoke any
>> > >setup or tear down tasks required by the test cases that will be
>> re-run.
>> > >- Setup or tear down tasks which reference executable targets
>> should
>> > >substitute the actual built executable just like how
>> add_custom_command()
>> > > does.
>> >
>>

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

On Tue, Aug 23, 2016 at 4:00 PM, Rolf Eike Beer <e...@sf-mail.de> wrote:

> Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott:
> > Cheeky way to get me more involved in contributing, but okay, I'll bite.
> ;)
> > Switching discussion to the dev list.
> >
> > So how would you want the feature to work? I'd suggest an initial set of
> > requirements something like the following:
> >
> >- Need to support the ability to define multiple setup and/or tear
> down
> >tasks.
> >- It should be possible to specify dependencies between setup tasks
> and
> >between tear down tasks.
> >- Individual tests need to be able to indicate which setup and/or tear
> >down tasks they require, similar to the way DEPENDS is used to specify
> >dependencies between test cases.
> >- When using ctest --rerun-failed, ctest should automatically invoke
> any
> >setup or tear down tasks required by the test cases that will be
> re-run.
> >- Setup or tear down tasks which reference executable targets should
> >substitute the actual built executable just like how
> add_custom_command()
> > does.
>
> -need a way to mark if 2 tests with the same setup/teardown can share
> those or
> if they need to run for every of them
> -the default for each test is "no s/t", which means it can't be run with
> any
> of the above in parallel (especially for compatibillity)[1]
> -need a way to tell if a test doesn't care about those
>
> 1) think of a database connector test: the test that will check what
> happens
> if no DB is present will fail if the setup step "start DB" was run, but not
> the teardown
>

So maybe that requires being able to specify that tests for resource XXX
and resource YYY cannot be executed concurrently. Maybe that's a separate
change that could be made independent of this proposed improvement, since
it would apply even for existing CMake functionality. I see the value, I'm
just trying to sort out what is really needed from what is nice-to-have but
could be done as a subsequent improvement later.



>
> > Some open questions:
> >
> >- Should setup and tear down tasks be defined in pairs, or should they
> >completely independent (this would still require the ability to
> specify a
> > dependency of a tear down task on a setup task)?
>
> The test could be "shutdown daemon" or "delete files" so I would keep them
> separated. They may be created by the same command, so they could be
> batched
> anyway.
>

Agreed, it seems clear now that keeping them separate is preferable.




>
> >- Should the setup and tear down tasks be defined by a new CTest/CMake
> >command or extend an existing mechanism (e.g. add_custom_command())?
>
> Don't clutter existing commands more than needed. If it's something new,
> then
> create a new command (they could still share C++ code). If it's basically
> the
> same as anything existing at the end then use that.
>

See my other email reply just now. I think re-using the existing commands
and concepts and adding the RESOURCE_SETUP and RESOURCE_CLEANUP test
properties might be the most seamless from an end user perspective. I might
change my mind once I dig into the CMake source code though. ;)




>
> >- If no test case has a dependency on a setup or tear down task,
> should
> >that task be skipped? Perhaps tasks need to have a flag which
> indicates
> >whether they always run or only if a test case depends on it.
>
> Keep backward compatibility. I.e. if I now add a new test with s/t, then
> every
> other test should still run (and succeed) as before.
>

Definitely. Existing projects should receive zero impact from any changes
made. New functionality should be opt-in.



>
> >- What terminology to use? Things like GoogleTest use terms like test
> >*fixtures* for this sort of thing. The terms setup and tear down are a
> >bit imprecise and cumbersome, so we would probably need something
> better
> >than those.
> >- Would it make sense for the ctest command line to support disabling
> >setup and/or tear down steps? I can see some potential scenarios where
> > this may be desirable, but maybe this is getting too ambitious for a
> > starting set of requirements.
>
> IMHO that doesn't make sense. One could think about an option to disable
> the
> s/t merging, i.e. that they are really called alone for every test.
>

To reduce complexity, I'm gravitating that way too. If you define a
setup/cleanup task, then why allow disabling it? If developers really want
that, they could wrap defining the setup/cleanup 

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

In my original thinking, I was of the view that if a setup/cleanup step
needed to be executed for each test rather than for the overall test run as
a whole, then perhaps the test itself should handle that rather than CMake.
The existing RESOURCE_LOCK functionality could then be used to prevent
multiple tests from running concurrently if they would interfere with each
other. Existing test frameworks like GoogleTest and Boost Test already have
good support for test fixtures which make doing this per-test setup/cleanup
easy. The problem I want to solve is where a group of tests share a common
(set of) setup/cleanup steps and CMake knows to run them when asked to run
any test cases that require them. The specific problem motivating this work
was running ctest --rerun-failed, where we need CMake to add in any
setup/cleanup steps required by any of the tests that will be rerun. With
that in mind, see further comments interspersed below.


On Fri, Aug 26, 2016 at 12:08 AM, Ben Boeckel <ben.boec...@kitware.com>
wrote:

> On Tue, Aug 23, 2016 at 08:00:09 +0200, Rolf Eike Beer wrote:
> > Am Dienstag, 23. August 2016, 10:06:01 schrieb Craig Scott:
> > > So how would you want the feature to work? I'd suggest an initial set
> of
> > > requirements something like the following:
> > >
> > >- Need to support the ability to define multiple setup and/or tear
> down
> > >tasks.
> > >- It should be possible to specify dependencies between setup tasks
> and
> > >between tear down tasks.
> > >- Individual tests need to be able to indicate which setup and/or
> tear
> > >down tasks they require, similar to the way DEPENDS is used to
> specify
> > >dependencies between test cases.
> > >- When using ctest --rerun-failed, ctest should automatically
> invoke any
> > >setup or tear down tasks required by the test cases that will be
> re-run.
> > >- Setup or tear down tasks which reference executable targets should
> > >substitute the actual built executable just like how
> add_custom_command()
> > > does.
> >
> > -need a way to mark if 2 tests with the same setup/teardown can share
> those or
> > if they need to run for every of them
>
> Proposal:
>
> add_test(NAME setup-foo ...)
> set_tests_properties(setup-foo PROPERTIES
>   SETUP_GROUP foo
>   SETUP_STEP SETUP_PER_TEST) # Also SETUP_ONCE.
> add_test(NAME use-foo ...)
> set_tests_properties(use-foo PROPERTIES
>   SETUP_GROUP foo) # implicit depends on all SETUP_GROUP foo /
> SETUP_STEP SETUP_* tests.
> add_test(NAME use-foo2 ...)
> set_tests_properties(use-foo2 PROPERTIES
>   SETUP_GROUP foo)
> add_test(NAME teardown-foo2 ...)
> set_tests_properties(teardown-foo2 PROPERTIES
>   SETUP_GROUP foo
>   SETUP_STEP TEARDOWN) # implicit depends on all non-TEARDOWN steps
>
> Multiple setup/teardown steps could be done with DEPENDS between them.
>

I like the idea of tests being associated with a group and the group itself
is where the setup/cleanup steps are attached/associated. That said, it
would seem that RESOURCE_LOCK already more or less satisfies this concept.
I'm wondering if we can't just somehow attach setup/cleanup steps to the
named resource instead. That would be a more seamless evolution of the
existing functionality and have little impact on any existing code.
Basically all we'd need to do is add the ability to associate the
setup/cleanup steps with a RESOURCE_LOCK label.

It's still not clear to me whether the setup/cleanup tasks should be
considered test cases themselves, but I can see benefits with taking that
path. It would mean all we'd need is to be able to mark a test case as
"this is a setup/cleanup step for RESOURCE_LOCK label XXX", maybe something
like this:

set_tests_properties(setup-foo PROPERTIES RESOURCE_SETUP foo)
set_tests_properties(teardown-foo PROPERTIES RESOURCE_CLEANUP foo)

If multiple setup/cleanup steps are defined for a particular resource, then
dependencies between those test cases would determine their order and where
there are no dependencies, the order would be undefined as is already the
case for test cases.

For the initial implementation at least, I think something like the
SETUP_PER_TEST concept is more complexity than I'd want to tackle. Maybe it
could be supported later, but in the first instance I think once per
group/resource is already a significant win and worth focusing on at the
start (see my motivation at the top of this email).



>
> > -the default for each test is "no s/t", which means it can't be run with
> any
> > of the above in parallel (especially for compatibillity)[1]
> > -need a way to tell if a test doesn't care about those
&

Re: [cmake-developers] [PATCH] FindOpenSSL: Fix detection of OpenSSL 1.1 w/ MSVC

[Craig Scott]

In that patch, the old names are listed before the new names, so if both
exist on the system, the older version would be found first. Would it be
preferable instead to swap the order to give preference to the newer
version in such a scenario?

On Mon, Aug 29, 2016 at 1:43 AM, Alexis Murzeau <amub...@outlook.fr> wrote:

> Since OpenSSL 1.1.0, Windows binaries are libcrypto and libssl instead of
> the old names libeay32 and ssleay32.
> When using MSVC, FindOpenSSL was searching for the old lib names only so
> this add the new names to be able to find OpenSSL 1.1.0 libraries.
>
> For example, the files in lib directory of OpenSSL 1.1.0 Win64 :
>  - libcrypto.lib
>  - libssl.lib
>  - VC/libcrypto64MD.lib
>  - VC/libcrypto64MDd.lib
>  - VC/libcrypto64MT.lib
>  - VC/libcrypto64MTd.lib
>  - VC/libssl64MD.lib
>  - VC/libssl64MDd.lib
>  - VC/libssl64MT.lib
>  - VC/libssl64MTd.lib
>
> 32 bits OpenSSL has the same file with "32" instead of "64" for files in
> VC directory.
>
> MinGW still works and use lib/libcrypto.lib and lib/libssl.lib.
> ---
>  Modules/FindOpenSSL.cmake | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/Modules/FindOpenSSL.cmake b/Modules/FindOpenSSL.cmake
> index 10b62ff..ba29a80 100644
> --- a/Modules/FindOpenSSL.cmake
> +++ b/Modules/FindOpenSSL.cmake
> @@ -133,6 +133,13 @@ if(WIN32 AND NOT CYGWIN)
>set(_OPENSSL_MSVC_RT_MODE "MD")
>  endif ()
>
> +# Since OpenSSL 1.1, lib names are like libcrypto32MTd.lib and
> libssl32MTd.lib
> +if( "${CMAKE_SIZEOF_VOID_P}" STREQUAL "8" )
> +set(_OPENSSL_MSVC_ARCH_SUFFIX "64")
> +else()
> +set(_OPENSSL_MSVC_ARCH_SUFFIX "32")
> +endif()
> +
>  if(OPENSSL_USE_STATIC_LIBS)
>set(_OPENSSL_PATH_SUFFIXES
>  "lib"
> @@ -150,7 +157,9 @@ if(WIN32 AND NOT CYGWIN)
>  find_library(LIB_EAY_DEBUG
>NAMES
>  libeay32${_OPENSSL_MSVC_RT_MODE}d
> +libcrypto${_OPENSSL_MSVC_ARCH_SUFFIX}${_OPENSSL_MSVC_RT_MODE}d
>  libeay32d
> +libcryptod
>NAMES_PER_DIR
>${_OPENSSL_ROOT_HINTS_AND_PATHS}
>PATH_SUFFIXES
> @@ -160,7 +169,9 @@ if(WIN32 AND NOT CYGWIN)
>  find_library(LIB_EAY_RELEASE
>NAMES
>  libeay32${_OPENSSL_MSVC_RT_MODE}
> +libcrypto${_OPENSSL_MSVC_ARCH_SUFFIX}${_OPENSSL_MSVC_RT_MODE}
>  libeay32
> +libcrypto
>NAMES_PER_DIR
>${_OPENSSL_ROOT_HINTS_AND_PATHS}
>PATH_SUFFIXES
> @@ -170,7 +181,9 @@ if(WIN32 AND NOT CYGWIN)
>  find_library(SSL_EAY_DEBUG
>NAMES
>  ssleay32${_OPENSSL_MSVC_RT_MODE}d
> +libssl${_OPENSSL_MSVC_ARCH_SUFFIX}${_OPENSSL_MSVC_RT_MODE}d
>  ssleay32d
> +libssld
>NAMES_PER_DIR
>${_OPENSSL_ROOT_HINTS_AND_PATHS}
>PATH_SUFFIXES
> @@ -180,8 +193,10 @@ if(WIN32 AND NOT CYGWIN)
>  find_library(SSL_EAY_RELEASE
>NAMES
>  ssleay32${_OPENSSL_MSVC_RT_MODE}
> +libssl${_OPENSSL_MSVC_ARCH_SUFFIX}${_OPENSSL_MSVC_RT_MODE}
>  ssleay32
>  ssl
> +libssl
>NAMES_PER_DIR
>${_OPENSSL_ROOT_HINTS_AND_PATHS}
>PATH_SUFFIXES
> --
> 2.7.4.windows.1
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers
>



-- 
Craig Scott
Melbourne, Australia
http://crascit.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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [CMake] Setup/tear down steps for CTest

[Craig Scott]

Cheeky way to get me more involved in contributing, but okay, I'll bite. ;)
Switching discussion to the dev list.

So how would you want the feature to work? I'd suggest an initial set of
requirements something like the following:

   - Need to support the ability to define multiple setup and/or tear down
   tasks.
   - It should be possible to specify dependencies between setup tasks and
   between tear down tasks.
   - Individual tests need to be able to indicate which setup and/or tear
   down tasks they require, similar to the way DEPENDS is used to specify
   dependencies between test cases.
   - When using ctest --rerun-failed, ctest should automatically invoke any
   setup or tear down tasks required by the test cases that will be re-run.
   - Setup or tear down tasks which reference executable targets should
   substitute the actual built executable just like how add_custom_command()
   does.

Some open questions:

   - Should setup and tear down tasks be defined in pairs, or should they
   completely independent (this would still require the ability to specify a
   dependency of a tear down task on a setup task)?
   - Should the setup and tear down tasks be defined by a new CTest/CMake
   command or extend an existing mechanism (e.g. add_custom_command())?
   - If no test case has a dependency on a setup or tear down task, should
   that task be skipped? Perhaps tasks need to have a flag which indicates
   whether they always run or only if a test case depends on it.
   - What terminology to use? Things like GoogleTest use terms like test
   *fixtures* for this sort of thing. The terms setup and tear down are a
   bit imprecise and cumbersome, so we would probably need something better
   than those.
   - Would it make sense for the ctest command line to support disabling
   setup and/or tear down steps? I can see some potential scenarios where this
   may be desirable, but maybe this is getting too ambitious for a starting
   set of requirements.
   - What should happen if a setup or tear down task fails? How would
   failure be detected? How would such failures impact things like a CDash
   test report, etc.?

I think that's probably enough to kick off discussions for now.



On Sun, Aug 21, 2016 at 11:41 PM, David Cole <dlrd...@aol.com> wrote:

> The best thing to do would be to add the feature to ctest, and
> contribute to the CMake community.
>
> I, too, use the "run this test first" and "that test last" technique,
> and set up DEPENDS property values to ensure ordering when all tests
> are run in parallel. However, as you noted, this does not work to run
> subsets of tests reliably. For me, I am able to live with the partial
> solution because the vast majority of my tests can be run
> independently anyhow and we usually do run all the tests, but a setup
> / teardown step for the whole suite would be a welcome addition to
> ctest.
>
> Looking forward to your patch...     :-)
>
>
> David C.
>
>
> On Sat, Aug 20, 2016 at 8:32 PM, Craig Scott <craig.sc...@crascit.com>
> wrote:
> > Let's say a project defines a bunch of tests which require setup and tear
> > down steps before/after all the tests are run (not each individual test,
> I'm
> > talking here about one setup before all tests are run and one tear down
> > after all tests have finished). While this could be done by a script
> driving
> > CTest itself, it is less desirable since different platforms may need
> > different driver scripts and this seems like something CTest should be
> able
> > to handle itself (if the setup/tear down steps use parts of the build,
> that
> > only strengthens the case to have them handled by CMake/CTest directly).
> >
> > It is possible to abuse the DEPENDS test property and define setup and
> tear
> > down "tests" which are not really tests but which perform the necessary
> > steps. While this mostly works, it is not ideal and in particular it
> doesn't
> > work with CTest's --rerun-failed option. I'm wondering if there's
> currently
> > a better way of telling CMake/CTest about a setup step which must be run
> > before some particular set of test cases and a tear down step after they
> are
> > all done. The tear down step needs to be performed regardless of whether
> any
> > of the real test cases pass or fail.
> >
> > The motivating case is to start up and shutdown a service which a (subset
> > of) test cases need running. That service is expensive to set up and
> hence
> > it isn't feasible to start it up and shut it down for every test case
> > individually.
> >
> > Any ideas?
> >
> > --
> > Craig Scott
> > Melbourne, Australia
> > http://crascit.com
> >
> > --
> >
> > Power