[cmake-developers] Missing Bullseye coverage on CMake Dashboard

[Nils Gladitz]

Hi,

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

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

Is that expected or did this break at some point?

Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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

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

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

Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 04.07.2018 18:52, Oleh Kravchenko wrote:


Hello CMake Developers!

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


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

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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 13.07.2017 22:19, Robert Dailey wrote:

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


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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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


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


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

This should not have been done without a new policy.

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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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


Hello CMake developers,

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

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

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

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


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


function(foo)
foo()
endfunction()

foo()

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 17.01.2017 23:25, Chris Bieneman wrote:

Hello CMake-developers!

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


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

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


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


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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 04.10.2016 11:20, Tobias Hunger wrote:

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

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

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

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

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


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


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


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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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


Hello,

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

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


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



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

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


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


Nils


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

--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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



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

Michael


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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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

Here it is.



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

Is that intentional or an oversight?

I think we should allow patching for both.

Nils


--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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


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


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

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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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

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



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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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



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



Please verify that I haven't broken anything.


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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

[Nils Gladitz]

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



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


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


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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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


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


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


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

Please verify that I haven't broken anything.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] PATCH: add custom xmlns namespaces into generated .wxs sources

[Nils Gladitz]

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


best regards,
Michael


Can you elaborate your use case for the patch?

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


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


Thanks.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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


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


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


Great. Thanks.



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

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


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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

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




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

Nils

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


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


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


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

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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Using the patchfile support I managed to implement the service installation 
issue I had, so the unnecessary features from the last patch are removed now.

I tested all patches separately and hope they work now.

looking forward for feedback,

best regrads,
Michael



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


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Using the patchfile support I managed to implement the service installation 
issue I had, so the unnecessary features from the last patch are removed now.

I tested all patches separately and hope they work now.

looking forward for feedback,

best regrads,
Michael


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


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


Nils
|
-- 

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 08/02/2016 01:29 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


-Original Message-
From: Nils Gladitz [mailto:nilsglad...@gmail.com]
Sent: Tuesday, August 02, 2016 10:47 AM
To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
Subject: Re: [cmake-developers] [Patch 3/5] Improved WIX support
Patch 3 looks OK but I think I would prefer using WiX over CPack
nomenclature in the variables you introduce.

e.g.

  CPACK_WIX_ROOT_FEATURE_TITLE and
  CPACK_WIX_ROOT_FEATURE_DESCRIPTION

over

  CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and
  CPACK_WIX_ROOT_COMPONENT_DESCRIPTION

given that CPack has no concept of a root component.

Would you agree?


totally.



Thanks. I added a release note, modified the commit message and merged 
to "next" for testing:

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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Using the patchfile support I managed to implement the service installation 
issue I had, so the unnecessary features from the last patch are removed now.

I tested all patches separately and hope they work now.

looking forward for feedback,

best regrads,
Michael


Patch 3 looks OK but I think I would prefer using WiX over CPack 
nomenclature in the variables you introduce.


e.g.

CPACK_WIX_ROOT_FEATURE_TITLE and
CPACK_WIX_ROOT_FEATURE_DESCRIPTION

over

CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and
CPACK_WIX_ROOT_COMPONENT_DESCRIPTION

given that CPack has no concept of a root component.

Would you agree?

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 21.07.2016 17:32, Brad King wrote:

On 07/21/2016 10:45 AM, Nils Gladitz wrote:

I amended the commit message and added the otherwise missing release note.

Thanks.  Currently the release note is:


+* The CPack WIX generator now supports CPACK_COMPONENT__DISABLED.
+  This can be used to deselect a component from being installed by default.

However, that option is not publicly documented as a variable for projects
to set.  Instead it is the internal representation of the `DISABLED` option
to `cpack_add_component`.  Please revise the commit message to reference
this command (as :command:`cpack_add_component`).


From CPack's point of view the CPACK_* variables are the public interface.
cpack_add_component() (and CPackComponent.cmake) are only involved when 
you use cmake to generate the cpack configuration.


So perhaps the variable should be documented instead?

CPACK_COMPONENT__DISABLED being undocumented might be an 
oversight to begin with given that e.g. 
"CPACK_COMPONENT__REQUIRED" is documented (also settable 
through cpack_add_component()).


Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Using the patchfile support I managed to implement the service installation 
issue I had, so the unnecessary features from the last patch are removed now.

I tested all patches separately and hope they work now.

looking forward for feedback,

best regrads,
Michael


I've merged patch 2 implementing CPACK_COMPONENT__DISABLED to 
"next" for testing:

https://cmake.org/gitweb?p=cmake.git;a=commit;h=4c52c4c2

I amended the commit message and added the otherwise missing release note.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

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

[Nils Gladitz]

On 07/20/2016 03:58 PM, Stuermer, Michael SP/HZA-ZSEP wrote:


Using the patchfile support I managed to implement the service installation 
issue I had, so the unnecessary features from the last patch are removed now.

I tested all patches separately and hope they work now.

looking forward for feedback,



To start with I don't think I really like the first patch as it is.

We should either require that install file locations are canonical 
(which is what I went for when I initially implemented them; I think I 
would still prefer it that way),

or perform more complete and consistent canonicalization. e.g.

- The implementation as-is only works with cmake's internal path 
separation (forward slash).
Given the canonical path "foo/bar" the path "foo\bar" does not 
currently work. So neither should a backslash work in a prefix e.g. 
".\foo/bar".
I'd also like to think of these paths as portable (should any other 
CPack generator choose to implement install properties as well) which is 
why I think we should not support (canonicalize) windows path separators 
anywhere in the path.


- Handling "." only as a singular prefix is inconsistent.
If we do implement this then ".." should also be supported and 
canonicalization should work anywhere in the path.
e.g. given the canonical path "foo/bar/baz" these should refer to 
the same path:

- "./foo/bar/baz"
- "././foo/bar/baz"
- "foo/./bar/baz"
- "foo/../foo/bar/baz"
etc.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Improved WIX support

[Nils Gladitz]

On 19.07.2016 17:43, Stuermer, Michael SP/HZA-ZSEP wrote:

Hello there,

in short:

I fixed some minor issues with WIX toolset support and added the possibility to 
integrate service installation/uninstallation with generated msi packages. 
Please review and comment what is missing for integration in upstream.

a bit longer:

When creating a component-based installer, the root component (or feature, as 
it is called in WIX context) cannot be named and described. This can now be 
done using CPACK_WIX_ROOT_COMPONENT_DISPLAY_NAME and 
CPACK_WIX_ROOT_COMPONENT_DESCRIPTION.

The install folder can only be set to a subfolder of ProgramFiles or ProgramFiles64. With the 
option CPACK_WIX_SKIP_PROGRAM_FOLDER it is now possible to set default installation paths on 
arbitrary locations such as "C:\myprogram". In order for this to work, the Guids of the 
WIX-Components must be explicitly set using CPACK_WIX_GENERATE_COMPONENT_GUIDS. Per default the 
Guids are auto generated using the value "*".

Disabling components by default using the 
CPACK_COMPONENT__DISABLED is now working.

With the install file properties CPACK_WIX_KEYPATH and 
CPACK_WIX_PROPERTY_ it is now possible to add custom tags (such as 
service handling) to the installer. If the custom tag depends on several files within 
the directory, bundling of several files in WIX-Components is needed. This can be 
done using CPACK_WIX_BUNDLE_COMPONENTS.

All new functionalities are documented and some small example snippets are 
added to the documentation.

I hope these changes make sense to you, if the documentation is not accurate 
enough or the naming of cmake properties/variables should be changed please let 
me know


Would you mind dividing these changes into feature sized patches that I 
can review, test and integrate individually?


Thanks!
Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Nils Gladitz]

On 07/01/2016 02:08 PM, Julien Schueller wrote:





*De: *"Nils Gladitz" <nilsglad...@gmail.com>
*À: *"Julien Schueller" <schuel...@phimeca.com>,
"cmake-developers" <cmake-developers@cmake.org>
*Envoyé: *Vendredi 1 Juillet 2016 13:57:40
*Objet: *Re: [cmake-developers] PATHS guess in find_package
ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE



On 07/01/2016 01:44 PM, Julien Schueller wrote:



--------

*De: *"Nils Gladitz" <nilsglad...@gmail.com>
*À: *"Julien Schueller" <schuel...@phimeca.com>,
"cmake-developers" <cmake-developers@cmake.org>
*Envoyé: *Vendredi 1 Juillet 2016 12:37:47
*Objet: *Re: [cmake-developers] PATHS guess in
find_package ignored with NO_DEFAULT_PATH &
CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

On 07/01/2016 11:13 AM, Julien Schueller wrote:


I'm using find_package in no-module mode with the
PATHS option to provide a hard-coded guess to a path
where a sublibrary 'hmat' was previously found,
and with the NO_DEFAULT_PATH to not find it first in
system directories.
find_package (HMAT REQUIRED NO_MODULE PATHS
/lib/cmake/hmat NO_DEFAULT_PATH)

So far so good. Now I want to cross-compile with the
usual toolchain file:
set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
...
This works wonderfully too.

But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to
ONLY in my toolchain file to prevent detecting native
libraries
set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
And now find_package fails to find my package!

I'm puzzled as I did not find in the doc something
that explains why the PATHS is ignored (step #8 in
find_package):

https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package


The given path "/lib/cmake/hmat" is prefixed
by the paths in CMAKE_FIND_ROOT_PATH.
Which means that (given ONLY) cmake only looks for the
package in
"/usr/i686-w64-mingw32//lib/cmake/hmat".

You might want to e.g. add  to
CMAKE_FIND_ROOT_PATH and use PATHS / instead.

Nils


Thanks,

In my case  has the same value as
CMAKE_FIND_ROOT_PATH, and even if I modify the PATHS option
value to be relative (PATHS lib/cmake/hmat) the detection fails.
(They're not actually set to /usr/i686-w64-mingw32 but some
absolute location in my home where I unzip a mingw toolchain,
but I can reproduce the issue on another box where the
toolchain is natively /usr/i686-w64-mingw32).


I don't think behavior for relative paths is defined.

Use absolute paths like "/lib/cmake/hmat", just "/" probably works
as well (since the path in the prefix matches
"/(lib/|lib|share)/cmake/*/").

Nils


Yes, if I use just "/lib/cmake/hmat" it works. Couldn't cmake see that 
that my absolute path begins with CMAKE_FIND_ROOT_PATH and hence 
should be treated as valid according 
to CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ?


CMake could do a lot of things but as-is the defined (documented) 
behavior is that when you tell cmake to only look in the prefixes 
provided by CMAKE_FIND_ROOT_PATH then all search locations are re-rooted 
to those prefixes.


e.g. a given path "/usr" can exist under your regular filesystem root 
and as /usr/i686-w64-mingw32/usr.
Still you would not want cmake to look in your native /usr directory in 
this case even though it is "valid" (exists).


Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] PATHS guess in find_package ignored with NO_DEFAULT_PATH & CMAKE_FIND_ROOT_PATH_MODE_PACKAGE

[Nils Gladitz]

On 07/01/2016 11:13 AM, Julien Schueller wrote:


I'm using find_package in no-module mode with the PATHS option to 
provide a hard-coded guess to a path where a sublibrary 'hmat' was 
previously found,

and with the NO_DEFAULT_PATH to not find it first in system directories.
find_package (HMAT REQUIRED NO_MODULE PATHS 
/lib/cmake/hmat NO_DEFAULT_PATH)


So far so good. Now I want to cross-compile with the usual toolchain file:
set (CMAKE_FIND_ROOT_PATH /usr/i686-w64-mingw32)
set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
...
This works wonderfully too.

But now I add CMAKE_FIND_ROOT_PATH_MODE_PACKAGE to ONLY in my 
toolchain file to prevent detecting native libraries

set (CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
And now find_package fails to find my package!

I'm puzzled as I did not find in the doc something that explains why 
the PATHS is ignored (step #8 in find_package):

https://cmake.org/cmake/help/v3.5/command/find_package.html#command:find_package



The given path "/lib/cmake/hmat" is prefixed by the paths 
in CMAKE_FIND_ROOT_PATH.
Which means that (given ONLY) cmake only looks for the package in 
"/usr/i686-w64-mingw32//lib/cmake/hmat".


You might want to e.g. add  to CMAKE_FIND_ROOT_PATH and use 
PATHS / instead.


Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 32 and 64 bit packages on Windows

[Nils Gladitz]

On 06/21/2016 03:37 PM, Brad King wrote:


Nils, the installers in question were produced from your WiX
installer work (thanks again for that!).  Is this something wrong
with the 64-bit installer or simply a Windows/MSI subtlety/bug?




I can't try this out here right now but looking at the windows installer 
documentation[1] applications should be automatically notified about 
environment variable changes performed by the .msi by the 
WM_SETTINGCHANGE message.


I am not sure which processes listen and act on the message.

Nils

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

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] How can we add Find****

[Nils Gladitz]

On 06/21/2016 10:57 AM, Farbos a wrote:

I was wondering how can we add new Find.cmake. For examples I
don't see any FindTBB, FindJsonCpp ... and I think some of them are
used a lot.

So my question is, Who decide if we can add new Find*** ?


See https://cmake.org/Wiki/CMake:Module_Maintainers

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindPkgConfig and IMPORTED_TARGET in 3.6.0

[Nils Gladitz]

On 06/17/2016 03:36 PM, Ben Boeckel wrote:

Nils, the IMPORTED_TARGET feature in pkg_check_modules is nice! Thanks
for that. However, it is hidden behind the check that pkg_check_modules
uses to see if it already ran:


I have not been involved in that development.
From what I can tell this is Eike's work.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] ninja/make compilation response file

[Nils Gladitz]

On 04.04.2016 18:38, Nils Gladitz wrote:

On 04.04.2016 17:59, Dmitry Ivanov wrote:


PS. Can we do something about bloated cmake ninja generator ? in our 
case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though 
ninja is still faster than make even in this case.




Curious. Did you count the accumulative size of all Makefile and 
Makefile2 files (also in sub-directories)?
For a project of mine the ninja files are only half in size of what is 
generated for the Makefile generator (CMake 3.5.1).


Oh and the Makefile generator also uses build.make files which actually 
seem to be where most of the size goes.


Nils

-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] ninja/make compilation response file

[Nils Gladitz]

On 04.04.2016 17:59, Dmitry Ivanov wrote:


PS. Can we do something about bloated cmake ninja generator ? in our 
case cmake generates 1.8 Mb Makefile and 84 Mb build.ninja, though 
ninja is still faster than make even in this case.




Curious. Did you count the accumulative size of all Makefile and 
Makefile2 files (also in sub-directories)?
For a project of mine the ninja files are only half in size of what is 
generated for the Makefile generator (CMake 3.5.1).


Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Nils Gladitz]

On 29.03.2016 23:34, Alan W. Irwin wrote:

On 2016-03-29 22:46+0200 Nils Gladitz wrote:


On 29.03.2016 21:39, Alan W. Irwin wrote:

One of the PLplot developers, Arjen Markus, has just reported to me
that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while
ctest works fine. This issue occurred for the
mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe,
and the PLplot build was done with the "MSYS Makefiles" generator. In
contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine
for the Linux case.

Has anyone else here had similar difficulties OR success with the
parallel ctest option on the MinGW-w64/MSYS2 platform?


Afair there are sporadic issues with the cygwin runtime (on which 
msys/msys2 is based) in the process handling code of kwsys (used by 
cmake).
The code is used by e.g. execute_process() and also ctest for test 
execution.


I think the issue is due to how pipes are implemented by the runtime.
From what I remember rsync also suffers from this.

Also having Kaspersky installed (even when paused) seems to make 
these hangs more likely.


Thanks, Nils, for that information.  Could this issue be related to
the Cygwin unreliability mentioned in
<http://cygwin.com/cygwin-ug-net/highlights.html> where they say "In
summary, current Windows implementations make it impossible to
implement a perfectly reliable fork, and occasional fork failures are
inevitable."?


Afair the issue was a wait or select on the pipes used to connect to the 
spawned process rather than fork but I haven't debugged into it myself.
I think there was a cygwin mailing list post on this too but I don't 
seem to be able to find it.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Parallel ctest issues on the MinGW-w64/MSYS2 platform

[Nils Gladitz]

On 29.03.2016 21:39, Alan W. Irwin wrote:

One of the PLplot developers, Arjen Markus, has just reported to me
that ctest -j4 for PLplot hangs on his MinGW-w64/MSYS2 platform while
ctest works fine. This issue occurred for the
mingw64/mingw-w64-x86_64-cmake 3.4.1-1 package version of ctest.exe,
and the PLplot build was done with the "MSYS Makefiles" generator. In
contrast to the MinGW-w64/MSYS2 platform case, ctest -j4 works fine
for the Linux case.

Has anyone else here had similar difficulties OR success with the
parallel ctest option on the MinGW-w64/MSYS2 platform?


Afair there are sporadic issues with the cygwin runtime (on which 
msys/msys2 is based) in the process handling code of kwsys (used by cmake).
The code is used by e.g. execute_process() and also ctest for test 
execution.


I think the issue is due to how pipes are implemented by the runtime.
From what I remember rsync also suffers from this.

Also having Kaspersky installed (even when paused) seems to make these 
hangs more likely.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] find_package with NO_MODULE while cross-compiling

[Nils Gladitz]

On 15.03.2016 23:01, Julien Schueller wrote:

Hi,

When using find_package ( NO_MODULE) while cross-compiling,
cmake may find an existing Config.cmake in the host root path if 
Config.cmake is not available in the target root path.


For example let's say that I have Qt5 project in my host Linux box, 
which provides a /usr/lib/cmake/.../Qt5WidgetsConfig.cmake.
In my cmake project I use: find_package (Qt5Widgets NO_MODULE), 
everything goes as planned.
Now I want to cross-compile using MinGW-w64, I install qt5 in my mingw 
target root, so I have a 
/usr/i686-w64-mingw32/lib/cmake/.../Qt5WidgetsConfig.cmake
I set CMAKE_FIND_ROOT_PATH to /usr/i686-w64-mingw32 and stuff via a 
toolchain file, and everything goes fine too.
No if I remove the qt5 target package for mingw, or it is unavailable 
in the first place, cmake prefers the host qt5 config file, and the 
compilation fails.


I found a workaround, which is to not let cmake use host rules to find 
Config.cmake in the case of cross-compiling:

if (CMAKE_CROSSCOMPILING)
  set (NO_MODULE_ARGS NO_MODULE NO_SYSTEM_ENVIRONMENT_PATH 
NO_CMAKE_SYSTEM_PATH)

endif ()
find_package (Qt5Widgets ${NO_MODULE_ARGS})
Would there be a smarter way to do this instead of invading each 
CMakeLists that uses a find_package relying on package-provided cmake 
configs ?


Setting 
https://cmake.org/cmake/help/v3.5/variable/CMAKE_FIND_ROOT_PATH_MODE_PACKAGE.html 
to ONLY in your toolchain file should prevent cmake from picking up 
native packages.


Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] BUG: ALL_BUILD not added to the PREDEFINED_TARGETS_FOLDER

[Nils Gladitz]

On 15.03.2016 21:44, Taylor Braun-Jones wrote:

On Tue, Mar 15, 2016 at 4:28 AM, Nils Gladitz <nilsglad...@gmail.com> wrote:

 https://cmake.org/Bug/view.php?id=15578
 https://cmake.org/Bug/view.php?id=15931

It seems like one of those reports should be marked as a duplicate of
the other, no?


Done ... not that it changes the implementation status in any way :)

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] BUG: ALL_BUILD not added to the PREDEFINED_TARGETS_FOLDER

[Nils Gladitz]

On 03/15/2016 08:27 AM, Petr Kmoch wrote:

Hi Taylor,

I am afraid this behaviour is by design, so that ALL_BUILD can be the 
first target in the generated solution and thus the Startup project by 
default.


However (speaking to the wider list audience), I would really 
appreciate an option to override this "by design" behaviour. For 
projects which actually use the generated solutions in the IDE for 
development and debugging (instead of just building it), ALL_BUILD is 
useless as a startup project anyway, and it brings an inconsistency to 
the Solution Explorer (not to mention the fact that it pushes to the 
fore a CMake feature which is not really necessary in VS, irritating 
"entrenched" Visual Studio users).


Would a patch introducing such an override option be considered 
acceptable?


Related changes were proposed and Brad didn't seem to object:
https://cmake.org/Bug/view.php?id=15578
https://cmake.org/Bug/view.php?id=15931

Just looks like no one got around to actually work on it.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] set_test_properties ignoring multiple properties

[Nils Gladitz]

On 08.03.2016 22:36, Kael Dai wrote:

Hi,

I have a test that outputs multiple lines and want to use 
set_tests_properties with the PASS_REGULAR_EXPRESSION property to 
check different lines in the output. I've tried doing


set_tests_properties(test1 PROPERTIES PASS_REGULAR_EXPRESSION "value1" 
PASS_REGULAR_EXPRESSION "value2")


I've also tried to split up the properties

set_tests_properties(test1 PROPERTIES PASS_REGULAR_EXPRESSION "value1")
set_tests_properties(test1 PROPERTIES PASS_REGULAR_EXPRESSION "value2")

In both cases, ctest is ignoring the test of "value1" and only 
checking if "value2" passes or not.


Is there any way to check multiple regular expression on the same test 
and check them all? The documentation for 3.1 seems to suggest you 
can, but it isn't working when building the tests.


The current documentation has an example on how to set the property with 
multiple values:

https://cmake.org/cmake/help/v3.5/prop_test/PASS_REGULAR_EXPRESSION.html

set_tests_properties() does not append to existing properties; it 
replaces them.
If you do want to append you can use set_property() with the APPEND 
keyword instead.


Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Appending to LINK_FLAGS property of a target doesn't seem to work correctly

[Nils Gladitz]

On 03.03.2016 22:57, Dan Liew wrote:

Hi,

I noticed recently is you do something like this

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

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

gcc -g -O0 -fopenmp;-static

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

Is this intentional or is this a bug?


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

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindBOOST 3.5 target

[Nils Gladitz]

On 01.03.2016 18:09, Henry Schreiner wrote:

On FindBoost.cmake (and maybe others), the new (in 3.5) targets populate the 
INTERFACE_INCLUDE_DIRECTORIES directory. Shouldn’t this be the 
INTERFACE_SYSTEM_INCLUDE_DIRECTORIES field? Since that way CMake can help keep 
Xcode and other IDE’s from claiming you have warnings in boost, etc.


All INTERFACE_INCLUDE_DIRECTORIES of IMPORTED targets are implicitly 
considered SYSTEM include directories.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Run program/command before test

[Nils Gladitz]

On 17.02.2016 07:58, Roman Wüger wrote:

Ok thanks

Would it be an opinion to have a COMMAND parameter for the add_test function 
like execute_process where every COMMAND must return the exit code and this 
would be ored?

add_test(MyTest COMMAND myserver --port 80
   COMMAND mytest
   COMMAND myserver --graceful-shutdown)

Or

add_test(MyTest PRE_COMMAND myserver --port 80
   COMMAND mytest
   POST_COMMAND myserver --graceful-shutdown)


What you could already do is wrap your test in a cmake script.

E.g.

add_test(NAME MyTest
COMMAND ${CMAKE_COMMAND} -DACTUAL_TEST=$ -P 
${CMAKE_CURRENT_SOURCE_DIR}/mywrapper.cmake

)

Where mywrapper.cmake could do something like:

execute_process(COMMAND mysever --port 80 ...)

execute_process(COMMAND ${ACTUAL_TEST} )

execute_process(COMMAND mysever --graceful-shutdown)

To have the test fail you could call message(FATAL_ERROR "...")

For this to work myserver would have to daemonize/fork (but I assume 
that is the case given your example).


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Is there a way to disable soname versioning?

[Nils Gladitz]

On 01.02.2016 00:09, Eric Wing wrote:

This has been an ongoing nuisance for me, so I thought I would finally
ask. Is there a way I can force soname versioning without modifying
everybody's CMake build scripts?

The main problem is Android. Using soname versioning on Android will
basically cause things to break at runtime. It would be nice if the
CMake commands that set the version would be ignored in the Android
case. (I know Android is not officially supported by CMake and
cross-compile toolchains are being used, but if I knew how to put this
in the toolchain, that would be a big help.)


The "Android" platform file included with CMake contains:
set(CMAKE_PLATFORM_NO_VERSIONED_SONAME 1)

Which should do just that.

All you should have to do for this to take effect is have:
set(CMAKE_SYSTEM_NAME Android)

In your toolchain file (instead of what ever you've got it set to now).

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Adding source files not built by targets to CMake project

[Nils Gladitz]

On 11/20/2015 04:43 PM, Marcus D. Hanwell wrote:

I would like to see these files listed in Qt Creator (or insert your
IDE of choice here). Is there anyway to do this, knowing that these
files are not going to be built for a target (or compiled in any way).
Any trick I am missing to make this work? When I include a .cmake file
I see it is added, so I feel like there is some plumbing already in
place to feed through these source files that are not built by
targets.


If they are related to an existing build target 
(add_executable()/add_library()) you can list them there with your 
regular sources.
Otherwise e.g. add_custom_target(my_custom_target SOURCES foo.py 
bar.json ...) should work.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] Directory listing for "Older Releases" no longer available

[Nils Gladitz]

Following https://cmake.org/files from the Download page [1] I get:
Directory index no longer supported. Please visit the download 
 page.


Is this intentional?

The directory listing for "Current development distribution" [2] still 
works.


Nils

[1] https://cmake.org/download/
[2] https://cmake.org/files/dev

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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] ALIAS target scope regression

[Nils Gladitz]

The commit
c389f8bb07e900d805ca3163f47b06e3dbe4303b cmLocalGenerator: Port 
Find method away from GetGeneratorTarget


seems to have broken the following reduced test case:
  cmake_minimum_required(VERSION 3.3)

  project(Foo CXX)

  file(WRITE sub/CMakeLists.txt [[
  file(WRITE foo.cpp "")

  add_library(foo STATIC foo.cpp)
  add_library(Foo::foo ALIAS foo)
  ]])

  add_subdirectory(sub)

  add_custom_target(bar ALL ${CMAKE_COMMAND} -E echo 
$)


At generation time this now produces the diagnostic:

  CMake Error at CMakeLists.txt:14 (add_custom_target):
Error evaluating generator expression:

  $

No target "Foo::foo"

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

[Nils Gladitz]

On 23.10.2015 16:52, Brad King wrote:

Thanks.  Fixed:

  CTest: Fix regression in handling of a RUN_SERIAL test that fails
  https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e61973e1

I've queued this for merge to 'release' for 3.4.0-rc3.

-Brad


Thanks!

Nils

--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake 3.4.0-rc2 cpack xz compressed debian packages broken

[Nils Gladitz]

Given this test case:
  cmake_minimum_required(VERSION 3.3)

  project(Foo NONE)

  install(FILES CMakeLists.txt DESTINATION tmp)

  set(CPACK_DEBIAN_COMPRESSION_TYPE "xz")
  set(CPACK_PACKAGE_CONTACT "f...@bar.com")

  include(CPack)

A debian package created with:
cpack -G DEB

Fails during installation with dpkg -i with:
  tar: Archive is compressed. Use -J option
  tar: Error is not recoverable: exiting now
  dpkg-deb: error: subprocess tar returned error exit status 2

The breaking commit seems to be:
7044e8ee4baa8250fd9c4e915b13d53c7f543ea3 CPackDeb: use of 
libarchive and removal of fakeroot


From the looks of it the contained "control.tar.gz" is now XZ 
compressed as well while it previously was gzip compressed.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

[Nils Gladitz]

I switched from 3.2.1 to 3.4.0-rc2 on a Windows and a Linux dashboard 
client for a custom project.


On the Linux client parallel testing now loops with 100% CPU somewhere 
in cmCTestMultiProcessHandler::StartNextTests and 
cmCTestMultiProcessHandler::CheckOutput.


I don't have a proper stack trace on the windows client but it seems to 
hang there too.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMake 3.4.0-rc2 ctest hangs with 100% CPU

[Nils Gladitz]

On 10/23/2015 09:10 AM, Nils Gladitz wrote:
I switched from 3.2.1 to 3.4.0-rc2 on a Windows and a Linux dashboard 
client for a custom project.


On the Linux client parallel testing now loops with 100% CPU somewhere 
in cmCTestMultiProcessHandler::StartNextTests and 
cmCTestMultiProcessHandler::CheckOutput.




I reduced it to this test case:

  cmake_minimum_required(VERSION 3.4)

  project(Foo NONE)

  enable_testing()

  add_test(NAME foo COMMAND command_not_found)
  set_property(TEST foo PROPERTY RUN_SERIAL ON)

  add_test(NAME bar COMMAND ${CMAKE_COMMAND} -E echo let_me_run)

The issue seems to exist for sequential ctest runs as well.

The breaking commit seems to be:
07c550caa20d4b1d6ebc08269d744ff6a45c0a6d 
cmCTestMultiProcessHandler: Refactor RUN_SERIAL implementation


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake fails to identify C and CXX compiler when building universal

[Nils Gladitz]

On 09/29/2015 04:38 AM, Ryan Schmidt wrote:

Hello, I am a developer with the MacPorts package management system, and I want 
to report to you a bug in cmake 3.3.2 that affects OS X.

I was going to file a bug report in your issue tracker, but the bright yellow box at the 
top of the "report issue" page made it sound like I should send my report here 
instead.

The problem is that cmake cannot identify the compiler, when compiling any 
project (that uses cmake) universally (i.e. for more than one architecture, 
e.g. for both x86_64 and i386):

-- cmake version 3.3.2
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown

This could cause programs that rely on identifying the compiler to either build 
incorrectly or even (e.g. in the case of x265) to fail to build at all. For 
cross-referencing purposes, this problem was previously reported to the 
MacPorts project here:

https://trac.macports.org/ticket/48331


Is it possible that beyond setting CMAKE_OSX_ARCHITECTURES the project 
also tries to manually add -arch flags to CFLAGS/CXXFLAGS?


The test binary produced for compiler identification with just 
CMAKE_OSX_ARCHITECTURES set is not a fat binary for me and 
identification is successful (CMake 3.3.2).


Manually adding "-arch x86_64 -arch i386" to the compiler flags breaks 
this since now the test binary itself is also fat.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Nils Gladitz]

On 04.08.2015 23:15, Dan Liew wrote:

foolib is defined in this CMakeLists.txt:
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt

That is the (only) context in which you can extend the definition of the
target with custom commands.

Since when?


As far as I know it has always been this way.


  I haven't seen that documented anywhere. IMHO this
behavior is counter-intuitive, in general I expect the scope of a
target to not depend on the cmake command I am trying to use.


I think it is sensible that the definition of a target is scoped to one 
single directory.
Where the definition of a target consists of e.g. sources, properties, 
dependencies and custom commands related to the target.


You can reference/query global targets in other directories but you can 
not change them.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] [BUG] add_custom_command(TARGET ...) can't see in scope target

[Nils Gladitz]

On 04.08.2015 22:46, Dan Liew wrote:


   The target name foolib is unknown in this context.
This warning is for project developers.  Use -Wno-dev to suppress it
```


This doesn't make sense the target **clearly exists and is in scope**
because the ``simple_test`` executable links against it and also it is
possible to read properties of the target.

Seems like there's some sort of weird scope issue going on here.




foolib is defined in this CMakeLists.txt:
https://github.com/delcypher/cmake_add_custom_command_bug/blob/master/lib/CMakeLists.txt

That is the (only) context in which you can extend the definition of the 
target with custom commands.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake-3.3.0-Linux-x86_64.tar.gz on download page is not gzipped

[Nils Gladitz]

On 07/31/2015 03:09 PM, Brad King wrote:

I think some browsers or other download tools may automatically
gunzip files during download.


I seem to get that with Chromium too.

The HTTP response for cmake-3.3.0.tar.gz does contain:
Content-Encoding: x-gzip

Which I think does tell clients that they should decompress to get the 
actual content which is declared to be of 
Content-Type:application/x-gzip; this is I think incorrect unless the 
HTTP server compresses the .tar.gz once more with gzip before delivery.


For cmake-3.3.0.zip of Content-Type: application/zip there is no 
Content-Encoding field in the HTTP response.


Maybe other clients have workarounds for these kinds of errors?

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMAKE_MAP_IMPORTED_CONFIG_* missing implementation?

[Nils Gladitz]

On 07/30/2015 03:28 PM, Brad King wrote:

On 07/30/2015 08:45 AM, Nils Gladitz wrote:

Am I missing something obvious?


It can only work for the configurations that CMake knows about.
For single-config generators (Makefiles, Ninja) this is the
value of CMAKE_BUILD_TYPE.  For multi-config generators they
are listed in CMAKE_CONFIGURATION_TYPES.


That makes perfect sense, thanks!

Nils


--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMAKE_MAP_IMPORTED_CONFIG_* missing implementation?

[Nils Gladitz]

I tried using 
http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_MAP_IMPORTED_CONFIG_CONFIG.html 
in the following example:


  cmake_minimum_required(VERSION 3.3)

  project(Foo CXX)

  set(CMAKE_MAP_IMPORTED_CONFIG_RELWITHDEBINFO Release)

  add_library(foo SHARED IMPORTED)

  get_property(VAR TARGET foo PROPERTY MAP_IMPORTED_CONFIG_RELWITHDEBINFO)

  message([${VAR}])

When configuring this produces the output [] where I would expect 
[Release].


Am I missing something obvious?

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015

[Nils Gladitz]

On 07/23/2015 03:47 PM, Konstantin Podsvirov wrote:

http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

CMake uses the module InstallRequiredSystemLibraries to install dependencies.
Who is in charge here on this module? Should this module to install Universal 
CRT
(api-ms-win-crt-runtime-xxx.dll library) for MSVC14 ?


  6. App-local deployment of the Universal CRT is not supported.

I think that means installation should not be handled by 
InstallRequiredSystemLibraries.


You should probably just require users to run Windows Update.

Nils


--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [MODERN] CMake 3.3 vs Qt 5.5 vs MSVC2015

[Nils Gladitz]

On 23.07.2015 17:24, James Johnston wrote:

That sounds horrible - asking a user to manually run Windows Update.  But
Windows Update packages don't have to be installed ONLY by way of visiting
Windows Update manually.


The support issue is certainly cumbersome given that users will be told 
that some DLL that they haven't heard of before is missing rather than 
that they need to update an operating system component by running 
windows update.


But this will only be an issue for users which don't run windows = 10 
or which don't run regular updates (I'd have assumed this comes in 
through automated updates as well unless disabled?).


Given sufficient time this should therefor become a non-issue.

I rather think it is nice that this is considered an operating system 
component rather than a visual studio version specific runtime component 
(e.g. reduced application installer sizes and centralized updates) but 
this might work best if you also treat it as such (unless you 
specifically have to target e.g. outdated/unnetworked machines).


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Compact dependency graph

[Nils Gladitz]

On 06/15/2015 09:46 PM, Richard Ulrich wrote:

So here is the patch with tests and passing the git hooks.


Thank you for the update and sorry again for the inconvenience.

- Your commit's subject line looks a bit too long; I'd move the issue 
number into the bulk of the message (It should nicely fit into the 
console in git log).


- In RegexReplacerCallback you've got lowercase members that start with 
underscore. I'd change that to follow the same convention you used in 
e.g. RegexReplacer (camel case starting upper case).


- I think the tests visible to ctest are a bit too granular. I would 
subsume related tests into one ctest visible test (e.g. as is done for 
CommandLineTar).


- The RunCMake.graphviz_no_filter and RunCMake.graphviz_filter_even 
tests currently seem to fail for me.


Comparing expected.dot with the actual output of e.g. 
RunCMake.graphviz_no_filter shows basically the same content but the 
node numbering is entirely different.


I'd try to see if either node numbering could be made consistent (I am 
not sure why it isn't) or use regular expression matching on the 
expected results instead (as is e.g. done by RunCMake for stderr/stdout).


Something like ...
 file(READ ... actual)
 file(READ ... expected)

 if(NOT actual MATCHES ${expected})
message(FATAL_ERROR ... ${actual} ... ${expected})
 endif()

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

[Nils Gladitz]

On 05/12/2015 07:23 AM, James Bigler wrote:

OK, thanks.

I still think that if there is a difference in behavior for Makefile
generators between MAIN_DEPENDENCY and DEPENDENCY there is a bug in
CMake.  Perhaps there needs to be bug filed for that.  Here's the
documentation:

In makefile terms this creates a new target in the following form::

  OUTPUT: MAIN_DEPENDENCY DEPENDS
  COMMAND

For a makefile, there shouldn't be a difference between the dependency
coming in on MAIN_DEPENDENCY or DEPENDENCY.  CMake is doing something
else with that property.


I would prefer that too but the add_custom_command() implementation 
which handles MAIN_DEPENDENCY and DEPENDENCY and attaches commands to 
source files is common to all generators.


Treating MAIN_DEPENDENCY and DEPENDENCY the same for Makefiles in this 
case would break existing projects (when using the Makefile generators) 
when they list the source file named by MAIN_DEPENDENCY but not the 
source file named by OUTPUT since then the custom command would not get 
emitted at all.




2. I'm curious why this causes a problem.  It seems to me that dummy.cpp
should be present by the time the add_custom_command is even run,


Yes, it is.


so why would it care whether it was created by CMake or anything else?


That isn't the issue.

The test case failure depends on the presence of the custom command but 
the custom command is not involved in creation of dummy.cpp; it only 
uses it as input.


Due to MAIN_DEPENDENCY the custom command is attached to dummy.cpp.

I think the issue is due to cmake trying to attach the command used to 
compile dummy.cpp itself as a custom command as well. [1]


Nils

[1] 
http://www.cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmLocalGenerator.cxx;h=88c88cd133a753fc319a785e116fdb8e6d5fd94a;hb=HEAD#l580

--

Powered by www.kitware.com

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

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

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/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 --help-policy CMP0057 MAIN_DEPENDENCY

[Nils Gladitz]

On 29.04.2015 09:11, Nils Gladitz wrote:

The policy will likely have to be removed or replaced.


I reverted the MAIN_DEPENDENCY specific CMP0057 commits and replaced the 
policy with an unrelated one that is part of my if-IN_LIST topic to 
fill the gap.


This leaves the original issues that prompted the creation of CMP0057 
open for now.


Two related but distinct issues are triggered by the following test 
cases with the Makefile generator:


1) The following causes the given custom command to be emitted for both 
the foo and bar target which can lead to parallel build errors:


  cmake_minimum_required(VERSION 3.2)

  file(WRITE test.in)
  file(WRITE dummy.cpp int main() {})

  add_custom_command(
  OUTPUT test.out
  COMMAND ${CMAKE_COMMAND} -E echo Hello World
  MAIN_DEPENDENCY test.in
  )

  add_executable(foo dummy.cpp test.in)
  add_executable(bar dummy.cpp test.in)

2) The following causes the compile step for the dummy.cpp source file 
to fail in presence of the custom command:


  cmake_minimum_required(VERSION 3.2)

  file(WRITE dummy.cpp int main() {})

  add_custom_command(
  OUTPUT test.out
  COMMAND ${CMAKE_COMMAND} -E echo Hello World
  MAIN_DEPENDENCY dummy.cpp
  )

  add_executable(foo dummy.cpp)

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

[Nils Gladitz]

On 04/28/2015 09:30 AM, Alan W. Irwin wrote:

OK.  Thanks, for pointing that out.  Could you make that more obvious
in http://www.cmake.org/cmake/help/v3.2/policy/CMP0026.html, i.e.
change the summary line from

Disallow use of the LOCATION target property.

==

Disallow use of the LOCATION property for build targets.


Thanks, I implemented your suggestion:

http://www.cmake.org/gitweb?p=cmake.git;a=commitdiff;h=853ef717;hp=397b6298602f1496d1b946f5db827f5807d6ed23

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Generator Expressions in CPack (Module) variables

[Nils Gladitz]

On 04/28/2015 10:57 AM, Gregor Jasny wrote:

Unfortunately the CPACK_BUILD_CONFIG approach does only work for
multi-config generators. As far as I understand CPACK_BUILD_CONFIG gets
only set if the -C command line option was given to cpack. But this
option is only added conditionally and omitted for Makefile builds:


void cmGlobalGenerator::CreateDefaultGlobalTargets(cmTargets* targets)
...
  if ( cmakeCfgIntDir  *cmakeCfgIntDir  cmakeCfgIntDir[0] != '.' )
{
singleLine.push_back(-C);
singleLine.push_back(cmakeCfgIntDir);
}


Now I'm just wondering if conditionally setting -C / CPACK_BUILD_CONFIG
is the right thing to do?


I don't know ... but as a local workaround you might be able to set 
CPACK_BUILD_CONFIG before include(CPack) conditionally when using 
single-configuration generators.


Assuming nothing else messes with CMAKE_BUILD_TYPE when using 
multi-configuration generators e.g.:


  if(CMAKE_BUILD_TYPE)
set(CPACK_BUILD_TYPE ${CMAKE_BUILD_TYPE})
  endif()

  include(CPack)

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

[Nils Gladitz]

On 04/28/2015 09:30 AM, Alan W. Irwin wrote:

I don't understand exactly what you mean by configuration LOCATION
returns.  From what you said that term means something different from
LOCATION_CONFIG and in any case is not relevant to my use case of
generating pkg-config *.pc files with our build system, but I am
nevertheless curious about what you meant.)


E.g. on windows with MSVC cmake target exports may refer to locations of 
both a Debug and a Release binary.


LOCATION returns the path to one of those two (you don't know which).

LOCATION_DEBUG and LOCATION_RELEASE would refer to the Debug and Release 
binary respectively.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Is there a way to avoid LOCATION property with Qt5?

[Nils Gladitz]

On 04/28/2015 08:00 AM, Alan W. Irwin wrote:

The Qt5 cmake documentation at
http://doc.qt.io/qt-5/cmake-manual.html which Steve has referred me
to before states you should use the LOCATION property of targets to
determine the actual path to libraries. The PLplot build system
requires those locations so it can transform them into the -L and -l
form required to generate its pkg_config *.pc files.

Some time ago I got this process to work fine for CMP0026 OLD and Qt5, but
what is the alternative I should use for the CMP0026 NEW case (which
disallows using the LOCATION property for targets)?

Note PLplot uses a minimum CMake version of 3.0.2 so I am looking for
a CMP0026 NEW solution that works for that version or above for Qt5.


CMP0026 only applies to build targets.

The location of build targets is still in flux during configuration 
which is why getting the location of those during configuration time is 
unsafe.


For imported targets this does not apply since their location is fixed.

For which configuration LOCATION returns isn't defined but I suppose 
that may not matter for pkg-config.


Otherwise you may want to look into LOCATION_CONFIG.

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

[Nils Gladitz]

On 04/27/2015 11:48 PM, James Bigler wrote:

The problem is the current detection only barfs (unless I missed
something - please correct if I'm wrong).  What we need is detection and
adaptation.  Rather than telling the user, DON'T DO THAT! we should be
helping the user out by saying, I know you wanted this to be attached
as a MAIN_DEPENDENCY, but that doesn't work, so I'm going to help you
out and disable this feature for this file.  Then I can specify
MAIN_DEPENDENCY and not worry about the collisions that cause problems.


Yes, I prefer the deterministic barfing that diagnoses documented 
restrictions over elusive build failures.


I am not opposed to your change if your implementation guarantees that 
the aforementioned build failures don't creep through again.


If I understand correctly you would still output a warning diagnostic 
when degrading duplicate MAIN_DEPENDENCY?


Not sure I would like that. Most CMake diagnostics generally imply 
something that the project developer can fix ... which isn't feasible if 
you make the behavior part of the design in FindCUDA.cmake.


On the other hand the user may himself use MAIN_DEPENDENCY outside the 
scope of FindCUDA.cmake in which case silent degrading isn't optimal 
either ... but I guess I could live with that.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake --help-policy CMP0057 MAIN_DEPENDENCY

[Nils Gladitz]

On 04/27/2015 03:31 PM, Brad King wrote:

The policy was added to diagnose some previously-broken cases earlier.
We technically never supported duplicate MAIN_DEPENDENCY specification
but did not diagnose it.  Instead it could produce bad builds in some
cases IIRC.

Nils, do you remember where this came up?


I think I covered this in:
  http://www.cmake.org/Bug/view.php?id=15525#c38598

Issues I know of (two of which I reported; including the above) are:
  http://www.cmake.org/Bug/view.php?id=14550
  http://www.cmake.org/Bug/view.php?id=15434
  http://www.cmake.org/Bug/view.php?id=15525

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] cmake 3.1.1 does not generate x64 profile for visual studio

[Nils Gladitz]

On 04/24/2015 02:22 PM, David Cole via cmake-developers wrote:

We really shouldn't have removed the explicit mention of the  Win64
suffixed generator names in the list of generators in --help ouput...

That was a mistake.

We should put it back.


As I understand it the generator suffixes aren't the preferred method to 
pick the architecture anymore.


You can now use the -A x64 option with the visual studio generators 
instead.


Also it looks like the supported target platforms aren't a fixed list 
that can be easily enumerated (e.g. WinCE-SDK [1])


Maybe instead of listing all known permutations in --help each generator 
(where the option is supported) could be listed with a well known subset 
of supported target platforms.


Nils

[1] 
http://www.cmake.org/cmake/help/v3.2/generator/Visual%20Studio%2011%202012.html

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Generator Expressions in CPack (Module) variables

[Nils Gladitz]

On 24.04.2015 20:55, Gregor Jasny wrote:

Hello,

would it be possible to add generator expression support to CPack
so that I can use $CONFIG within CPACK_PACKAGE_FILE_NAME? I'm
using the CPack module from within my CMakeLists.txt.

I'm trying to generate unique file names per architecture and
configuration but multi config generators like Xcode make this
harder than expected.

Before digging into that topic I'd like to know if this would be
a dead end.



You should be able to do this without generator expressions and just 
CPACK_PROJECT_CONFIG_FILE [1] and CPACK_BUILD_CONFIG [2].
If you really do require/want generator expressions you should be able 
to combine that with file(GENERATE) and include().


Nils

[1] 
http://www.cmake.org/cmake/help/v3.2/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE
[2] Set by cpack to the configuration being packaged (e.g. Debug, 
Release, ...)

[3] http://www.cmake.org/cmake/help/v3.2/command/file.html
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Bug in CMake GUI 3.2.1?

[Nils Gladitz]

On 04/13/2015 04:28 PM, Robert Dailey wrote:

I am running on Windows 8.1. Screenshots attached.


Those are options for cmake itself rather than for the compiler:
  http://www.cmake.org/cmake/help/v3.2/manual/cmake.1.html

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CTest update broken with non-ASCII filenames

[Nils Gladitz]

On 09.04.2015 20:39, Rolf Eike Beer wrote:

Am Donnerstag, 9. April 2015, 10:30:35 schrieb Brad King:

On 04/09/2015 10:28 AM, Nils Gladitz wrote:

What was the original problem you were trying to fix?

You pointed out test failures on nibble.ngladitz which I then tried to
fix:

https://open.cdash.org/testDetails.php?test=316350872build=3711574

Right, I forgot about that, thanks.  So, this was exposed by
using the zh_HK locale.

Just guessing: C will be ASCII, i.e. every 8 bit character gets mangled
(or at least everything not being able to be displayed in a 256 byte
codepage). So a fix could be to use something like en_US.UTF-8, if that is
available on the system, which sadly may not always be the case.


I merged c-locale-messages which tries to preserve LC_CTYPE (which 
affects filename encodings) in the presence of LC_ALL and sets 
LC_MESSAGES to C (which affects output messages).

This does seem to fix both cases for me.

Forcing UTF-8 might not be the correct way to go since people might be 
using other encoding beyond ASCII and UTF-8.
It has been a while but I think I used to run linux distros with e.g. 
something similar to en_US.ISO-8859-1.
Haven't seen anything like that since but I am not really that familiar 
with what other system use ... also aren't locale names themselves 
platform specific?


I implemented this outside of CTest hoping this might be something that 
could be reused elsewhere as well.
Since running external processes with english ASCII messages is a common 
pattern I was thinking it could be added to e.g. execute_process() with 
a new e.g. C_LOCALE_MESSAGES flag?


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CTest update broken with non-ASCII filenames

[Nils Gladitz]

On 04/09/2015 04:15 PM, Brad King wrote:

On 04/09/2015 07:54 AM, Nils Gladitz wrote:

With c771f9d945444f6cfe41195e26653f368aff7f42 CTest: To enforce the C
locale use LC_ALL instead of LC_MESSAGES.


I think you meant commit 6a661f06:

  CTest: To enforce the C locale use LC_ALL instead of LC_MESSAGES.
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6a661f06


Yes, sorry ... not sure how that happened.




I broke svn updates for repositories which contain non-ASCII filenames.

This is apparently due to me not only changing how messages are encoded
but also how svn interprets filename encodings.

I'll try to find a more appropriate fix.


Thanks.  If you are not able to find a good approach soon please
revert the original change.


Will do.


What was the original problem you were trying to fix?


You pointed out test failures on nibble.ngladitz which I then tried to 
fix:


https://open.cdash.org/testDetails.php?test=316350872build=3711574

Nils

--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CTest update broken with non-ASCII filenames

[Nils Gladitz]

With c771f9d945444f6cfe41195e26653f368aff7f42 CTest: To enforce the C 
locale use LC_ALL instead of LC_MESSAGES.

I broke svn updates for repositories which contain non-ASCII filenames.

This is apparently due to me not only changing how messages are encoded 
but also how svn interprets filename encodings.


I'll try to find a more appropriate fix.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Fortran support for Ninja generator

[Nils Gladitz]

On 03/24/2015 10:08 AM, Steven Vancoillie wrote:

Dear all,

we have a large Fortran project which we build with cmake and I'm
interested in making the ninja generator work with Fortran. I found a
few short discussions of this on the mailing list, but since then
nothing has happened.

One mention was to use the -M* flags supported by gfortran, just as
with gcc. However, when I tried this approach I found out that the -M*
flag for gfortran seems buggy, it doesn't output the correct format
(e.g. the target given with -MT flag is just added instead of
overwriting the default target). So, my ninja build failed saying the
depfile format was wrong.

Alternatively someone proposed to have ninja use cmake-generated
dependencies. From what I can tell from the ninja documentation, would
this mean that the cmake executable needs to generate the depfile
instead of the compiler?

I'm willing to work on this, but so far my experience with the cmake
source code is very rudimentary. If someone can point me in the right
direction, or provide some input to get started, this would be greatly
appreciated.


I am not very familiar with fortran myself but there was this discussion 
on the ninja mailing list that implied that this might also require 
changes to ninja itself:


https://groups.google.com/d/msg/ninja-build/b1-AF3pRJuE/NkPDsO0C2IUJ

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Nils Gladitz]

On 15.03.2015 16:42, Tobias Hunger wrote:

Hi Peter,

CMake does know all the headers or it could not decide which files
need rebuilding.


The build system that CMake generates knows the header dependencies and 
decides when which files need rebuilding.
CMake itself doesn't know. How header dependencies are determined and 
where and how they are recorded is generator specific.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Generating buildsystem metadata from CMake

[Nils Gladitz]

On 03/11/2015 11:10 AM, Stephen Kelly wrote:

I'm starting to gather requirements and make sure the feature is
well designed to satisfy the needs we're already aware of, and fits with
the features CMake currently has.


Source file groups (as in defined by source_group()) and target folders 
(as in the FOLDER target property) may be of interest to IDEs to layout 
target and source file hierarchies.


Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Wrong behavior with 3.2.0-rc2

[Nils Gladitz]

On 03/06/2015 10:22 AM, Pere Mato Vila wrote:

Using version 3.2.0-rc2 on the Mac OS X 10.10 with the make generator.
The following example executes the custom to create A.txt and B.txt
twice when building with make -jN

-
cmake_minimum_required(VERSION 2.8.8 FATAL_ERROR)
add_custom_target(Main ALL DEPENDS A.txt B.txt)
add_custom_command(OUTPUT A.txt B.txt
COMMAND touch A.txt
COMMAND touch B.txt)

-
$ make clean
$ make -j10
-- Configuring done
-- Generating done
-- Build files have been written to:
/Users/mato/Development/ROOT/build.master/temp
[100%] [100%] *Generating A.txt, B.txt*
*Generating A.txt, B.txt*
[100%] Built target Main


This is not the case for version 3.1.3.


This seems to be the case since
[644b4688d71cc52f8499d6103495de0909319557] Makefile: Fix rebuild with 
multiple custom command outputs (#15116)


Nils
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CTestCoverageCollectGCOV and ctest_submit(CDASH_UPLOAD)

[Nils Gladitz]

Hi,

I saw ctest_submit(CDASH_UPLOAD)signature and the 
CTestCoverageCollectGCOV module being added to CMake.


I was wondering how these differ in functionality from the old 
ctest_coverage() and ctest_upload(FILES).


Specifically I couldn't tell from the existing documentation what new 
use cases or features the new implementations support.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] cmake install command expected performance?

[Nils Gladitz]

On 02/23/2015 04:13 PM, Robert Goulet wrote:

I’m running into an issue were using the CMake install command to copy a
directory with over 5000+ files (slightly over 1GB of data) takes a lot
more time than doing a simple copy. On an SSD drive it takes 0.2 seconds
to copy, while it takes about 56+ seconds for CMake to do the same thing
using the install command. Why is there so much a big difference? Is
this intended for some reasons or could there be a bug? Thanks!


Did you run the manual copy right after the cmake install? (e.g. could 
files still have been in the system's disk cache?).


Both a manual copy and a cmake install might omit copying if the source 
isn't newer than the destination file; did you perform both with the 
destination files missing?


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] build on multiple cores

[Nils Gladitz]

On 01/27/2015 04:52 PM, Deepak Garg wrote:

I want to build my cmake code with multiple cores (64). For this I am
trying to test the build on 4 cores by typing

make -j 4

But still build is done by a single core. The time taken for build by

make  and  make -j 4

is same. Can anyone guide me that what am I doing wrong?


I think this might be better discussed on the user's rather than 
developer's mailing list.


In general this works for me as-is (with gnu make).

Nils


--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindOpenMP and gfortran

[Nils Gladitz]

On 11/18/2014 04:10 PM, Alin Marin Elena wrote:

the original bug/feature was introduced by this
https://www.cmake.org/Bug/view.php?id=14656history=1


@Brad: Could this be fixed in time for 3.1?

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] FindOpenMP and gfortran

[Nils Gladitz]

On 11/20/2014 02:32 PM, Brad King wrote:

On 11/18/2014 10:10 AM, Alin Marin Elena wrote:

2. the fortran test in FindOpenMP.cmake shall be provided in fixed
form (add 6 empty spaces in front of the character of each line)


Please use this approach in a topic based of origin/release.


Thanks, done.

@Alin I hope you don't mind that I took the liberty :)

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [PATCH] New module FindLibDl

[Nils Gladitz]

On 19.11.2014 20:23, Roger Leigh wrote:

libdl (for dlopen, dlsym) is part of (or an extention to) the
standard library/linker on many platforms.  It doesn't currently
have support in CMake, though there are a few independent
implementations shown up by Google.  Given that there are
several upstreams and that it's a basic component of several
different POSIX systems, having support in CMake would be quite
beneficial.


There is http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_DL_LIBS.html
which is set up by the platform modules.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] $BUILD_INTERFACE genex regression

[Nils Gladitz]

cmTarget: Refactor ComputeLinkImplementation (24637979):
  http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=24637979

Seems to have broken this reduced testcase:
  cmake_minimum_required(VERSION 3.0)

  set(LIBRARIES
  foobar.lib
  barfoo.lib
  )

  add_executable(foo foo.cpp)
  target_link_libraries(foo PUBLIC $BUILD_INTERFACE:${LIBRARIES})

For the Ninja generator in 3.0 this produces a build.ninja with:
  LINK_LIBRARIES = -rdynamic -lfoobar.lib -lbarfoo.lib

Since 24637979 this produces:
  LINK_LIBRARIES = -rdynamic $BUILD_INTERFACE:foobar.lib -lbarfoo.lib

I can work around this by wrapping the libraries with $BUILD_INTERFACE 
individually or by quoting the entire genex.


Given the title of the commit I'm guessing this wasn't an intentional 
change of behavior?


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Ninja RC cmcldeps regression

[Nils Gladitz]

On 10/10/2014 01:10 PM, Nils Gladitz wrote:

Ninja on windows invokes the resource compiler through cmcldeps.

When passing ${CMAKE_BINARY_DIR} as an include directory CMake used to
(3.0) add the absolute path to the command line; now -I. is being
added instead.

The relative path does not seem to work in context of cmcldeps/rc since
headers in ${CMAKE_BINARY_DIR} aren't found anymore.


This seems to have broken with cmLocalGenerator: Simplify 
GetIncludeFlags output formatting (b9aa5041):

  http://www.cmake.org/gitweb?p=cmake.git;a=commit;h=b9aa5041

I used the following test case to reproduce the issue:

  cmake_minimum_required(VERSION 3.0)

  file(WRITE foo.cpp int main() {})
  file(WRITE foo.rc #include bar.rc)
  file(WRITE ${CMAKE_BINARY_DIR}/bar.rc )

  add_executable(foo foo.cpp foo.rc)

  target_include_directories(foo PRIVATE ${CMAKE_BINARY_DIR})


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] $BUILD_INTERFACE genex regression

[Nils Gladitz]

On 10/10/2014 03:14 PM, Brad King wrote:

I can work around this by wrapping the libraries with $BUILD_INTERFACE
individually or by quoting the entire genex.


This was the intended interface.

I'm willing to regress this because:

- It restores 2.8.12 behavior
- The quoting is easy to do
- It is very hard to fix this without un-doing all the other
   improvements enabled by the refactoring that broke this.

I will add mention of this in the 3.1 release notes.


Good enough for me, thanks!

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Ninja RC cmcldeps regression

[Nils Gladitz]

On 10/10/2014 04:11 PM, Brad King wrote:

Thanks, fixed and test added:

  Ninja: Fix RC include directories regression
  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=23c8eeb7


Thanks!

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Severe regression caused by #14972 fixes

[Nils Gladitz]

On 10/07/2014 04:09 PM, Bill Hoffman wrote:

On 10/7/2014 8:47 AM, Brad King wrote:

Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972

fixes on, we can no longer compile ReactOS.

Also, if you really care about ReactOS, you could run a nightly cmake
dashboard.  Or it is almost certain that it will get broken again.  If
we are not testing it, it is broken...

http://www.cmake.org/testing/


To clarify as far as I understand it this particular issue is with 
building ReactOS on regular Windows rather than using CMake under ReactOS.


Which of course doesn't mean that there shouldn't be a dashboard for it 
nonetheless :)


Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Severe regression caused by #14972 fixes

[Nils Gladitz]

On 10/07/2014 04:56 PM, Adam Strzelecki wrote:


(1) Are these .spec, .inf or .idl generated by some custom commands?
(2) If yes, are these files specified as an output of these subcommand 
commands? If no, why?


From what I remember from the IRC discussion ...

They are regular (not generated) source files that are listed as 
dependencies (but not outputs) of custom commands.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Any ideas for accessing the Dart source code?

[Nils Gladitz]

On 10/08/2014 12:46 AM, Alan W. Irwin wrote:

I thought it would be interesting to install my own local dart server
to learn how to use CTest as a dart client.


You probably want the newer Kitware maintained replacement CDash:
http://www.cdash.org/

Additional instructions for a local installation can be found here:
http://public.kitware.com/Wiki/CDash:Installation

CMake's own CDash Dashboard can be seen in action here:
http://open.cdash.org/index.php?project=CMake

Nils
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] CMP0053 - Simplify variable reference and escape sequence evaluation - regression

[Nils Gladitz]

CMP0053 warns/fails on $ENV{ProgramFiles(x86)}.

Could () be added to the legal set of characters when within an $ENV{} 
expansion?


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] CMP0053 - Simplify variable reference and escape sequence evaluation - regression

[Nils Gladitz]

On 10/06/2014 02:48 PM, Brad King wrote:

On 10/06/2014 06:39 AM, Nils Gladitz wrote:

CMP0053 warns/fails on $ENV{ProgramFiles(x86)}.

Could () be added to the legal set of characters when within an $ENV{}
expansion?


We considered that case and decided to ask users to use a
nested variable reference for that case.  There is a similar
workaround in Modules/Platform/WindowsPaths.cmake.

One reason is that adding more characters to the allowed set,
especially as a special case for $ENV{}, triggers extra tests
and branches inside a tight loop that is used everywhere.


All right, no problem; I'll work around it.

Thanks!

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] kwsys SystemTools::RelativePath()

[Nils Gladitz]

On 04.10.2014 02:25, David Cole wrote:

Is the result of RelativePath guaranteed to be a directory name, or is
it possibly a file name?


If the second operand is a path to a file the result is a path to a file.
If the second operand is a path to a directory the result is a path to a 
directory.


The first operand can only be a path to a directory.

A path can not at the same time refer to a file and a directory.

So when both operands are the same path this gives that they, as well as 
the result, can only be directory paths.


Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] kwsys SystemTools::RelativePath()

[Nils Gladitz]

On 03.10.2014 21:13, Brad King wrote:

On 09/30/2014 10:05 AM, Nils Gladitz wrote:

When both operands are the same absolute path I get the empty string as
a result.

Should it be .?

Perhaps.  One would need to track down existing call sites
to see where that might affect behavior.  IIRC it is exposed
through file(RELATIVE_PATH), so it may need a policy.  That
is probably overkill because there are legitimate use cases
where an empty string looks better than ..


I guess that might be a matter of definition.
I wouldn't consider the empty string a valid path though I understand 
that this may be what people expect now given that this behavior has 
already been established.


I've worked around the issue I had with the wix-fix-root-dir-prop 
topic for now so there is no immediate need to change behavior before 
the 3.1 release.


Thanks  for the feedback.

Nils
--

Powered by www.kitware.com

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

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

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

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

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

[cmake-developers] kwsys SystemTools::RelativePath()

[Nils Gladitz]

When both operands are the same absolute path I get the empty string as 
a result.


Should it be .?

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Windows rpath emulation

[Nils Gladitz]

On 09/20/2014 11:53 PM, Nils Gladitz wrote:

On 20.09.2014 23:31, Roland Schulz wrote:

it would be nice if there were a way to emulate rpath under Windows.
As far as I can see there are two possible approaches:
- Generate a shell script which sets PATH
- Generate a manifest for the application and a manifest for the
dependencies.
http://sourceforge.net/p/mingw-w64/mailman/message/30019971/ has an
example of how to do it.


So I am thinking opt-in (target property) wrapper binaries that take the 
place of the actual binaries.


e.g.
  # Initializes ENABLE_EXECUTABLE_WRAPPER target property
  set(CMAKE_ENABLE_EXECUTABLE_WRAPPER ON)

  add_executable(foo foo.cpp)

Could produce
  foo.exe.real# Actual target binary
  foo.exe.wrapper # CMake generated configuration file
  foo.exe # Wrapper binary that reads foo.exe.wrapper, 
sets up the environment and runs foo.exe.real


COMMANDs (add_custom_command()/add_custom_target()/add_test()) could 
transparently call foo.exe (like they would have done without the wrapper).


install(TARGETS) should ignore the wrapper and transparently install and 
rename the real binary.


$TARGET_FILE should continue to point at the real binary.
A new $TARGET_WRAPPER could point at the wrapper binary.

The wrapper binary itself could be precompiled and included with cmake 
itself. It would determine which configuration to read and which binary 
to run by inspecting its own name.


I primarily had windows native builds in mind.
Are there additional use cases?

Nils

--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Windows rpath emulation

[Nils Gladitz]

On 09/23/2014 03:11 PM, David Cole wrote:

What is the problem that this feature is trying to solve?


Being able to run binaries with DLL dependencies within the build tree.
Basically the same thing that the build time RPATH feature does on e.g. 
linux.


If you are e.g. linking to Qt5 (shared) and don't have the Qt5 bin 
directory in your PATH the binary will not run since it can not locate 
the DLL on its own.


As workarounds people often copy the DLLs into their build directories,
output all runtime files into a single directory and/or set up custom 
wrappers that set up PATH.



But if you do pursue something like this, it seems to me that
install(TARGETS ...) should install all files including the wrapper.


CMake replaces build time RPATHs with installation RPATHs when deploying.

I think the same should apply to these wrappers. They are only useful 
for a build tree.



Is this only for executable files, or would something like this also
be possible/necessary for shared libraries, too?


I have been pondering DLLs as well but would restrict it to executables 
for now. For DLLs this probably only makes sense in a context where the 
DLL is build by CMake and used as-is without deployment in a context 
outside of CMake's control.


Also I am guessing this might not be as simple to set up as it is for 
executables.


Thanks for the feedback!

Nils
--

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] [CMake] Windows rpath emulation

[Nils Gladitz]

On 23.09.2014 19:12, Roland Schulz wrote:


Have you got a solution to the problem you mentioned in your first email:

I suppose it might be slightly more complex given that the import
library that is being linked to and the DLL that corresponds to the
import library might not be in the same location (and cmake might know
the location of the one but not always the location of the the other).




- For local targets CMake does have the location (these are also 
interesting but the main selling point would imo be external libraries).


- For imported targets CMake may have DLL locations.
More likely when set up by package configuration files (e.g. Qt5 sets 
them) than when set up by find modules (e.g. FindQt4 does not set them).
There might be incentive to add those locations when they start to be 
more useful.


- It might be possible to guess the DLL location from a given import 
library (assuming it was provided with a full path); probably not 
something you can rely on but it might be able to guess the location 
often enough to be convenient


- Additional locations could be provided manually by target property


On windows when you deploy to a system different from your own it
is expected and common practice that you deploy your runtime
requirements as well.
You can not expect a preexisting installation of your library
requirements nor can you expect them to be in the same location as
in your development system.


I think you are referring to making a binary cpack installation 
package. I was thinking about installing on the build system. Then It 
would still be different from the build directory.


Yes, but I think that is the least common use case (maybe even more so 
on windows).
CPack uses the same install commands for packaging and local install and 
I don't think CMake makes the distinction between deploying locally and 
remotely.


Nils
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [cmake-developers] Extracting target metadata, IDE integration

[Nils Gladitz]

On 09/20/2014 09:57 PM, Tobias Hunger wrote:

Hello!

Sorry for breaking the threading, I only joined this ML just now to
comment on this thread:-) Thanks Stephen for pointing me here!

I am not a regular cmake user (used to be a couple of years ago), but
I im interested in this topic since I work on Qt Creator. While cmake
currently is not our focus, I would personally like to see better
cmake integration into our tool. Unfortunately I do not have the time
to work on this myself:-/

I do want to provide some input to this discussion though.

 From my experience we would need a bit more information than proposed
in 
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=1100

This is the structure suggested for each target:

snip
   {
 name: testc1,
 type: STATIC_LIBRARY,
 directory: /tmp/COnly-bld,
 location: /tmp/COnly-bld//libtestc1.a,
 exportName: testc1,
 backtrace: [/tmp/COnly-src/CMakeLists.txt:6],
 installed: false
   },
snip

That information will be valuable.

I would love to see two additional field with information:

The first is should this be run in a terminal or is this a GUI. Not
sure whether cmake has that information.


At least on windows where there are distinct link time subsystems for 
console and gui applications the information is known; don't think it is 
available anywhere else(?)




Secondly the linker flags would be nice to know. That way the
LD_LIBRARY_PATH can be set correctly by the IDE so that all the
libraries are found.


That might not be necessary since CMake automatically constructs build 
time RPATHs by default.


Might be nice for platforms where RPATHs aren't supported (e.g. Windows) 
though a generic, non IDE specific solution might be preferable:


http://public.kitware.com/pipermail/cmake-developers/2014-September/011373.html

Nils
--

Powered by www.kitware.com

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

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

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

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

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