[CMake] get complete list of compile definitions

[Robert Schwarzelt]

Just in case anyone is interested - I found a hint in this old thread:
https://cmake.org/pipermail/cmake/2014-February/056993.html

Trick is to use a generator expression like this:
"$"

Regards,
Robert Schwarzelt


-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake --graphviz not dumping custom target in the graph

[Eric Noulard]

I did not try that.
It appears that none of my custom target do belong to ALL.
I'll try right away and let you know.

2017-03-29 14:30 GMT+02:00 Craig Scott :

> Does the behavior change if your custom target is part of the ALL target
> or not?
>
> On Wed, Mar 29, 2017 at 10:37 PM, Eric Noulard 
> wrote:
>
>> Hi all,
>>
>> It appears that  cmake --graphviz command line option does not dump
>> custom target
>> in the generated dot graph but "only" target appearing in add_executable
>> or add_library (plain or IMPORTED).
>>
>> Is there any fundamental reason for that ?
>>
>> I'd like to see ALL target (including custom) in my dependency graph.
>>
>> --
>> Eric
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/cmake
>>
>
>
>
> --
> Craig Scott
> Melbourne, Australia
> https://crascit.com
>



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] Fwd: cmake --graphviz not dumping custom target in the graph

[Eric Noulard]

-- Forwarded message --
From: Eric Noulard 
Date: 2017-03-29 17:50 GMT+02:00
Subject: Re: [CMake] cmake --graphviz not dumping custom target in the graph
To: Craig Scott 


After checking this does not change.
It seems that the only targets that appear in the graph are the one from
add_executable/add_library

In fact the culprit seems to be:

https://gitlab.kitware.com/cmake/cmake/blob/master/
Source/cmGraphVizWriter.cxx

cmGraphVizWriter::GenerateForTargetType

which filters out other kind of target.

2017-03-29 16:46 GMT+02:00 Eric Noulard :

> I did not try that.
> It appears that none of my custom target do belong to ALL.
> I'll try right away and let you know.
>
> 2017-03-29 14:30 GMT+02:00 Craig Scott :
>
>> Does the behavior change if your custom target is part of the ALL target
>> or not?
>>
>> On Wed, Mar 29, 2017 at 10:37 PM, Eric Noulard 
>> wrote:
>>
>>> Hi all,
>>>
>>> It appears that  cmake --graphviz command line option does not dump
>>> custom target
>>> in the generated dot graph but "only" target appearing in add_executable
>>> or add_library (plain or IMPORTED).
>>>
>>> Is there any fundamental reason for that ?
>>>
>>> I'd like to see ALL target (including custom) in my dependency graph.
>>>
>>> --
>>> Eric
>>>
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at:
>>> http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more
>>> information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/cmake
>>>
>>
>>
>>
>> --
>> Craig Scott
>> Melbourne, Australia
>> https://crascit.com
>>
>
>
>
> --
> Eric
>



-- 
Eric



-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] ZERO_CHECK generation and Xcode

[Steven Velez]

If I understand correctly the purpose of the ZERO_CHECK target is to update
the generated project files when necessary.

That's fine, but I have noticed on Xcode (8.2) that when ZERO_CHECK runs
and updates the project, it causes the xcode build to abort.
Unfortunately, it seems this build abort happens before the xcode project
regeneration has a chance to complete and update/touch
CMakeFiles/cmake.check_cache, so once the target is out of date, it pretty
much stays that way, and the builds are always (or least frequently)
subsequently aborted because of an update to generated project files.

If I go in to the terminal and manually execute "make -f ReRunCMake.make"
then the process completes and the ZERO_CHECK target is good, and it does
not run any more.

Is there any known way to deal with this other than by specifying
CMAKE_SUPRRESS_REGENERATION:BOOL=YES ?

Thanks,
Steven
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ZERO_CHECK generation and Xcode

[Gregor Jasny via CMake]

Hi Steven,

On 3/29/17 5:24 PM, Steven Velez wrote:
> If I understand correctly the purpose of the ZERO_CHECK target is to update
> the generated project files when necessary.
> 
> That's fine, but I have noticed on Xcode (8.2) that when ZERO_CHECK runs
> and updates the project, it causes the xcode build to abort.
> Unfortunately, it seems this build abort happens before the xcode project
> regeneration has a chance to complete and update/touch
> CMakeFiles/cmake.check_cache, so once the target is out of date, it pretty
> much stays that way, and the builds are always (or least frequently)
> subsequently aborted because of an update to generated project files.
> 
> If I go in to the terminal and manually execute "make -f ReRunCMake.make"
> then the process completes and the ZERO_CHECK target is good, and it does
> not run any more.
> 
> Is there any known way to deal with this other than by specifying
> CMAKE_SUPRRESS_REGENERATION:BOOL=YES ?

Could you please file a bug about this? I'll take a look during the 3.9
development cycle. Do you have a rather large or small project?

Thanks,
Gregor

-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] assembly on windows

[Tiago Macarios]

Hi,

Is there a simple way to get a Visual Studio + assembly project on windows?

This seems to work on Linux:

cmake_minimum_required(VERSION 3.7)
project(assembler C ASM)
set_source_files_properties(hello.s PROPERTIES COMPILE_FLAGS "-x
assembler-with-cpp")
add_executable(hello hello.s)

What would be the windows version of the above?

If I naively try the code above on Windows I get the following output:

-- Building for: Visual Studio 15 2017
-- The C compiler identification is MSVC 19.10.25017.0
-- The ASM compiler identification is MSVC
-- Found assembler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual
Studio/2017/Enterprise/VC/Tools/MSVC/14.10.25017/bin/HostX86/x86/cl.exe --
works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Warning: Did not find file Compiler/MSVC-ASM
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/Mac/test/cmake/build

and build fails

Thanks!
Mac
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] ZERO_CHECK generation and Xcode

[Gregor Jasny via CMake]

On 3/29/17 10:15 PM, Steven Velez wrote:
> I do have a pretty large project with around 142 targets.
> 
> Another characteristic of note, and which I noticed while investigating
> this is that our project suffers from
> https://gitlab.kitware.com/cmake/cmake/issues/14297, and I think it is
> because we have "project" declarations underneath the top-level... so
> ZERO_CHECK builds concurrently with other targets.

Oh boy. Thanks for pointing this out.

> I did create an xcode scheme that builds a smaller set of targets (6), and
> made sure that they all depended on ZERO_CHECK, and then ZERO_CHECK ran by
> itself, and it appeared that after a single test, it did manage to complete
> updating so that it did not run on subsequent invocations.

I'll have a look.
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] include() doesn't work with relative paths?

[Robert Dailey]

This fails:

include( foo/bar/myscript.cmake )

But this works:

include( ${CMAKE_CURRENT_LIST_DIR}/foo/bar/myscript.cmake )

Why are relative paths not working?
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Building third party libraries along with normal targets

[Florent Castelli]

On 30/03/2017 02:10, Robert Dailey wrote:

Interested in hearing everyone's thoughts on this idea of mine.

Right now I have several third party libraries: openssl, boost,
libpng, zlib, etc. List goes on. I need to support these libraries on
at least 3 different platforms: ARM android, x86 linux, x86 windows.
It's a real pain in the rear to build each of these libraries a total
of 3 times (once per platform). It makes upgrades painful.

So I was thinking: If I set up each third party library to build from
source as a normal target with the rest of my targets, this would get
me the libraries for each third party lib "for free". Basically, they
would all build the same way no matter what platform I'm on. I can
move to other platforms or architectures in the future with no extra
effort.

This is known as "super build".
Yes, this is exactly why I made my Boost CMake build scripts, which you 
use unless you changed your mind today :)
It can be done for other projects as well. Sometimes, they even provide 
CMake build scripts you can use directly with "add_subdirectory()" so 
you don't have to write CMake scripts or use "ExternalProject_Add()" 
(which isn't all great since it doesn't propagate all your current 
project settings).



The downside, of course, is that they build along with my normal
targets. Which means doing "ninja clean" will clean them, when I
really don't need to, and it will make build times get longer.
You can use ccache or its Windows variants to make it faster. But you 
also shouldn't need "ninja clean" most of the time. Possibly, you could 
just clean a specific target "ninja -t clean foo".
If you declare all your dependencies properly, then you could just 
always run "ninja" and the build will just be correct.
If your purpose is to see the compiler output again (to fix warnings), 
it is acceptable to clean and rebuild (with ccache it should be fast 
enough).
Personally, I just have a very long history in my terminal and scroll 
back or pipe the build content to a file to look at it later. Some IDEs 
will also record all the compilation output and make it available later 
(Xcode does it), then it's less of an issue.



Any thoughts on this idea? Are there any other downsides? Is this the
best way to have library support across platforms?


The downside is that you have to maintain lots of 3rd party build 
scripts. Depending on the side of the project, it might be a big 
overhead for the team. But it might also be totally worth it in order to 
support a lot of platforms, it just makes it easier than handling a huge 
matrix of binaries for each platform, arch and compiler and compiler 
options.


"Hey, you want to try LTO? Just add the flag and it's done!".

/Florent

--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Building third party libraries along with normal targets

[Robert Dailey]

On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
 wrote:
> This is known as "super build".
> Yes, this is exactly why I made my Boost CMake build scripts, which you use
> unless you changed your mind today :)

You mean this?
https://github.com/Orphis/boost-cmake

It's on the drawing board, for sure. It's the best solution I've
found. It's also part of the reason I'm asking this question to begin
with.

Although, this specific method of building boost doesn't use
superbuild, it uses normal add_subdirectory() with target.

> It can be done for other projects as well. Sometimes, they even provide
> CMake build scripts you can use directly with "add_subdirectory()" so you
> don't have to write CMake scripts or use "ExternalProject_Add()" (which
> isn't all great since it doesn't propagate all your current project
> settings).

Long term, I'm thinking a project like hunter[1] would be the best
choice. The problem with hunter is that it doesn't separate concerns
between host machine and target host. Specifically, when cross
compiling.

All the superbuild commands assume linux command syntax, simply
because I specified a toolchain utilizing android NDK. For this reason
it requires a lot of TLC to get working.

[1]: https://github.com/ruslo/hunter

> You can use ccache or its Windows variants to make it faster. But you also
> shouldn't need "ninja clean" most of the time. Possibly, you could just
> clean a specific target "ninja -t clean foo".
> If you declare all your dependencies properly, then you could just always
> run "ninja" and the build will just be correct.
> If your purpose is to see the compiler output again (to fix warnings), it is
> acceptable to clean and rebuild (with ccache it should be fast enough).
> Personally, I just have a very long history in my terminal and scroll back
> or pipe the build content to a file to look at it later. Some IDEs will also
> record all the compilation output and make it available later (Xcode does
> it), then it's less of an issue.

Never used ccache before, what does it do? Also if even if you ninja
-t to clean, it will also clean dependencies. So if I specify those
in-project dependencies that actually build third party libs, those
will be cleaned too.
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Building third party libraries along with normal targets

[Florent Castelli]

On 30/03/2017 03:54, Robert Dailey wrote:

On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
 wrote:

This is known as "super build".
Yes, this is exactly why I made my Boost CMake build scripts, which you use
unless you changed your mind today :)

You mean this?
https://github.com/Orphis/boost-cmake

It's on the drawing board, for sure. It's the best solution I've
found. It's also part of the reason I'm asking this question to begin
with.

Although, this specific method of building boost doesn't use
superbuild, it uses normal add_subdirectory() with target.
It doesn't "super build" its dependencies, you have to provide them 
externally, but it is a possible addition.
But it is designed to be part of a super build environment and is used 
as such at some large companies shipping to millions of people.





It can be done for other projects as well. Sometimes, they even provide
CMake build scripts you can use directly with "add_subdirectory()" so you
don't have to write CMake scripts or use "ExternalProject_Add()" (which
isn't all great since it doesn't propagate all your current project
settings).

Long term, I'm thinking a project like hunter[1] would be the best
choice. The problem with hunter is that it doesn't separate concerns
between host machine and target host. Specifically, when cross
compiling.

All the superbuild commands assume linux command syntax, simply
because I specified a toolchain utilizing android NDK. For this reason
it requires a lot of TLC to get working.

[1]: https://github.com/ruslo/hunter
There are those issues and also ABI changing flags that can become an 
issue as they aren't always propagated from what I can see.



You can use ccache or its Windows variants to make it faster. But you also
shouldn't need "ninja clean" most of the time. Possibly, you could just
clean a specific target "ninja -t clean foo".
If you declare all your dependencies properly, then you could just always
run "ninja" and the build will just be correct.
If your purpose is to see the compiler output again (to fix warnings), it is
acceptable to clean and rebuild (with ccache it should be fast enough).
Personally, I just have a very long history in my terminal and scroll back
or pipe the build content to a file to look at it later. Some IDEs will also
record all the compilation output and make it available later (Xcode does
it), then it's less of an issue.

Never used ccache before, what does it do? Also if even if you ninja
-t to clean, it will also clean dependencies. So if I specify those
in-project dependencies that actually build third party libs, those
will be cleaned too.


It's a program you use to record compilation outputs and save them to a 
disk cache. If you build a file again, instead of compiling it, it will 
just fetch the outputs from the cache and return the same warnings. It's 
usually a safe optimization in a build pipeline and is quite easy to use 
with CMake and Ninja generator.


It works well with GCC or Clang and there are some alternative versions 
for the Microsoft compiler too.


/Florent

--

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Building third party libraries along with normal targets

[Robert Dailey]

On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli
 wrote:
> On 30/03/2017 03:54, Robert Dailey wrote:
>>
>> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
>>  wrote:
>>>
>>> This is known as "super build".
>>> Yes, this is exactly why I made my Boost CMake build scripts, which you
>>> use
>>> unless you changed your mind today :)
>>
>> You mean this?
>> https://github.com/Orphis/boost-cmake
>>
>> It's on the drawing board, for sure. It's the best solution I've
>> found. It's also part of the reason I'm asking this question to begin
>> with.
>>
>> Although, this specific method of building boost doesn't use
>> superbuild, it uses normal add_subdirectory() with target.
>
> It doesn't "super build" its dependencies, you have to provide them
> externally, but it is a possible addition.
> But it is designed to be part of a super build environment and is used as
> such at some large companies shipping to millions of people.
>
>>
>>> It can be done for other projects as well. Sometimes, they even provide
>>> CMake build scripts you can use directly with "add_subdirectory()" so you
>>> don't have to write CMake scripts or use "ExternalProject_Add()" (which
>>> isn't all great since it doesn't propagate all your current project
>>> settings).
>>
>> Long term, I'm thinking a project like hunter[1] would be the best
>> choice. The problem with hunter is that it doesn't separate concerns
>> between host machine and target host. Specifically, when cross
>> compiling.
>>
>> All the superbuild commands assume linux command syntax, simply
>> because I specified a toolchain utilizing android NDK. For this reason
>> it requires a lot of TLC to get working.
>>
>> [1]: https://github.com/ruslo/hunter
>
> There are those issues and also ABI changing flags that can become an issue
> as they aren't always propagated from what I can see.
>
>>> You can use ccache or its Windows variants to make it faster. But you
>>> also
>>> shouldn't need "ninja clean" most of the time. Possibly, you could just
>>> clean a specific target "ninja -t clean foo".
>>> If you declare all your dependencies properly, then you could just always
>>> run "ninja" and the build will just be correct.
>>> If your purpose is to see the compiler output again (to fix warnings), it
>>> is
>>> acceptable to clean and rebuild (with ccache it should be fast enough).
>>> Personally, I just have a very long history in my terminal and scroll
>>> back
>>> or pipe the build content to a file to look at it later. Some IDEs will
>>> also
>>> record all the compilation output and make it available later (Xcode does
>>> it), then it's less of an issue.
>>
>> Never used ccache before, what does it do? Also if even if you ninja
>> -t to clean, it will also clean dependencies. So if I specify those
>> in-project dependencies that actually build third party libs, those
>> will be cleaned too.
>
>
> It's a program you use to record compilation outputs and save them to a disk
> cache. If you build a file again, instead of compiling it, it will just
> fetch the outputs from the cache and return the same warnings. It's usually
> a safe optimization in a build pipeline and is quite easy to use with CMake
> and Ninja generator.
>
> It works well with GCC or Clang and there are some alternative versions for
> the Microsoft compiler too.

At the end of the day, I've solved the Boost problem but I have many
other libraries I still manually build: openssl, libpng, zlib, etc.
It's as you said, maintaining build scripts for all of these will be
challenging but I think that's the proper way to go in my specific
situation (multi platform). It'll be less maintenance than rebuilding
binaries 3x per each.

Do you know how to set up the boost cmake project I linked on github
to work with superbuild? And do you prefer your superbuild execution
to happen during cmake generate (basically cmake invokes itself for
the superbuild) or do you prefer a separate external run, independent
of the normal one (basically 2x cmake invocations)?

Do you know of similar projects for other libraries I mentioned? Could
hand write my own, but seems better to piggyback on someone else's
efforts.

Thanks for your feedback!
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] Building third party libraries along with normal targets

[Florent Castelli]

On 30/03/2017 04:38, Robert Dailey wrote:

At the end of the day, I've solved the Boost problem but I have many
other libraries I still manually build: openssl, libpng, zlib, etc.
It's as you said, maintaining build scripts for all of these will be
challenging but I think that's the proper way to go in my specific
situation (multi platform). It'll be less maintenance than rebuilding
binaries 3x per each.

Do you know how to set up the boost cmake project I linked on github
to work with superbuild? And do you prefer your superbuild execution
to happen during cmake generate (basically cmake invokes itself for
the superbuild) or do you prefer a separate external run, independent
of the normal one (basically 2x cmake invocations)?

Do you know of similar projects for other libraries I mentioned? Could
hand write my own, but seems better to piggyback on someone else's
efforts.

Thanks for your feedback!


Only a few libraries are tricky to build, libpng or zlib are trivial for 
example.


A super-build is just having one big project and defining all the 
targets directly in there, using external CMake build scripts through 
add_subdirectory() for example. There is just one CMake invocation.
This is how my Boost CMake project (yes, I'm the one being it) works. As 
for the Boost dependencies, are you really using them? If you're not, 
then you don't need to build the parts of Boost using them, most are 
optional.
If you do, then you can provide Find*.cmake scripts returning targets 
you've built yourself currently. Feel free to create issues on the bug 
tracker if you need assistance with that.


I don't know on the top of my head similar projects for all libraries, 
but I know there are many people writing CMake build scripts for all 
kind of libraries, so just search on the web :)


/Florent

--

Powered by www.kitware.com

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

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

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

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

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

[CMake] Building third party libraries along with normal targets

[Robert Dailey]

Interested in hearing everyone's thoughts on this idea of mine.

Right now I have several third party libraries: openssl, boost,
libpng, zlib, etc. List goes on. I need to support these libraries on
at least 3 different platforms: ARM android, x86 linux, x86 windows.
It's a real pain in the rear to build each of these libraries a total
of 3 times (once per platform). It makes upgrades painful.

So I was thinking: If I set up each third party library to build from
source as a normal target with the rest of my targets, this would get
me the libraries for each third party lib "for free". Basically, they
would all build the same way no matter what platform I'm on. I can
move to other platforms or architectures in the future with no extra
effort.

The downside, of course, is that they build along with my normal
targets. Which means doing "ninja clean" will clean them, when I
really don't need to, and it will make build times get longer.

Any thoughts on this idea? Are there any other downsides? Is this the
best way to have library support across platforms?
-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] gnu-arm-embedded toolchain and CMAKE_FORCE_C_COMPILER

[Wagner Martin]

Hi @all,

In recent CMake versions I get a deprecated message for using the 
cmake_force_xxx_compiler() function inside my toolchain file. After searching, 
I found that there are two threads on the CMake list, one
https://cmake.org/pipermail/cmake/2016-February/062773.html
just ending without a solution and referencing to
https://cmake.org/pipermail/cmake-developers/2016-February/027888.html
which also doesn’t really tell me how this is supposed to work in my case. 
From those threads, I was able to modify my toolchain file:
- replaced force_compiler function with regular set(CMAKE...
- added line set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) as linking needs 
a linker script.
However, it fails with the following output:

exit.c:(.text.exit+0x1a): undefined reference to `_exit'
collect2: error: ld returned 1 exit status

which to me indicates that CMake ignores the STATIC_LIBRARY flag and tries 
linking.

Has anyone successfully modified their toolchain file to correctly detect the 
gnu-arm-embedded toolchain?

Thanks for your help!

Regards,
Martin

Terminal output:
~~
-- The C compiler identification is GNU 6.2.1
-- The CXX compiler identification is GNU 6.2.1
-- Check for working C compiler: 
/opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc
CMake Error at 
/home/user/workspace/project/buildsupport/toolchains/toolchain_stm32f303xB_freertos.cmake:37
 (include):
  include could not find load file:


/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeTmp/buildsupport/toolchains/toolchain_arm-cortex-m4f.cmake
Call Stack (most recent call first):
  
/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CMakeSystem.cmake:6
 (include)
  
/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeTmp/CMakeLists.txt:2
 (project)


CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working C compiler: 
/opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc -- broken
CMake Error at /usr/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:51 
(message):
  The C compiler
  "/opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc" is not
  able to compile a simple test program.

  It fails with the following output:

   

  
-- Configuring incomplete, errors occurred!
See also 
"/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeOutput.log".
See also 
"/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/CMakeError.log".

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:17 (project)
~~
CMakeOutput.log

The target system is: Generic -  - arm-freertos-eabi
The host system is: Linux - 4.9.0-1-amd64 - x86_64
Compiling the C compiler identification source file "CMakeCCompilerId.c" 
succeeded.
Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc 
Build flags: 
;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL;
Id flags: -c

The output was:
0


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
produced "CMakeCCompilerId.o"

The C compiler identification is GNU, found in 
"/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdC/CMakeCCompilerId.o"

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" 
succeeded.
Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ 
Build flags: 
;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL;
Id flags: -c

The output was:
0


Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" 
produced "CMakeCXXCompilerId.o"

The CXX compiler identification is GNU, found in 
"/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdCXX/CMakeCXXCompilerId.o"

Compiling the C compiler identification source file "CMakeCCompilerId.c" 
succeeded.
Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-gcc 
Build flags: 
;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL;
Id flags: -c

The output was:
0


Compilation of the C compiler identification source "CMakeCCompilerId.c" 
produced "CMakeCCompilerId.o"

The C compiler identification is GNU, found in 
"/home/user/workspace/project/build/release/arm-cortex-m4f_stm32f303/CMakeFiles/3.7.2/CompilerIdC/CMakeCCompilerId.o"

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" 
succeeded.
Compiler: /opt/gcc-arm-freertos-eabi-6_2-2017q1/bin/arm-freertos-eabi-g++ 
Build flags: 
;-DSTM32F303xC;-mcpu=cortex-m4;-mfpu=fpv4-sp-d16;-mfloat-abi=hard;-mthumb;--specs=nano.specs;-D_REENT_SMALL;
Id flags: 

[CMake] get complete list of compile definitions

[Robert Schwarzelt]

Hi all,
I need to implement a code export function, that will only export code used
in a specific project configuration.
For this purpose I want to use unifdef (http://dotat.at/prog/unifdef/),
which is capable of removing unused #ifdef blocks.

The project uses static libraries like in following example:

add_library(
foo STATIC
foo.c
)

add_library(
bar STATIC
bar.c
)

target_compile_definitions(bar INTERFACE HAVE_BAR)
target_link_libraries(foo LINK_PUBLIC bar)


Now foo.c will be compiled with -DHAVE_BAR at build time.
To create a custom target using unifdef i need this information at cmake
configure time. I expected to find this in the property COMPILE_DEFINITIONS
of either the source file foo.c or target foo, but both are empty.

Does anyone know, how to get a list of definitions (that will be used at
build time) for targets or files?

Regards,
Robert Schwarzelt


-- 

Powered by www.kitware.com

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

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

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

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

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

[CMake] cmake --graphviz not dumping custom target in the graph

[Eric Noulard]

Hi all,

It appears that  cmake --graphviz command line option does not dump custom
target
in the generated dot graph but "only" target appearing in add_executable
or add_library (plain or IMPORTED).

Is there any fundamental reason for that ?

I'd like to see ALL target (including custom) in my dependency graph.

-- 
Eric
-- 

Powered by www.kitware.com

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

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

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

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

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

Re: [CMake] cmake --graphviz not dumping custom target in the graph

[Craig Scott]

Does the behavior change if your custom target is part of the ALL target or
not?

On Wed, Mar 29, 2017 at 10:37 PM, Eric Noulard 
wrote:

> Hi all,
>
> It appears that  cmake --graphviz command line option does not dump custom
> target
> in the generated dot graph but "only" target appearing in add_executable
> or add_library (plain or IMPORTED).
>
> Is there any fundamental reason for that ?
>
> I'd like to see ALL target (including custom) in my dependency graph.
>
> --
> Eric
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/
> opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>



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

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-626-gc9728d7

[Kitware Robot]

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

The branch, next has been updated
   via  c9728d7adef051ae309d8dfa3cce1f505936e4cf (commit)
   via  b070947dffd141d50227c59feed4c3d784b39157 (commit)
   via  42c68aadf81a47d563392421636e14ef77644e03 (commit)
  from  bdc5141f31e33ab4516a46fcee6e612baa583f84 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c9728d7adef051ae309d8dfa3cce1f505936e4cf
commit c9728d7adef051ae309d8dfa3cce1f505936e4cf
Merge: bdc5141 b070947
Author: Brad King 
AuthorDate: Wed Mar 29 14:31:25 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 10:31:27 2017 -0400

Stage topic 'ctest-disable-tests'

Topic-id: 22988
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/571


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b070947dffd141d50227c59feed4c3d784b39157
commit b070947dffd141d50227c59feed4c3d784b39157
Author: Betsy McPhail 
AuthorDate: Mon Mar 27 14:08:50 2017 -0400
Commit: Brad King 
CommitDate: Wed Mar 29 10:29:57 2017 -0400

Add 'DISABLED' test property

When this property is set, the test is skipped and its status is
automatically set to 'Not Run'.  A disabled test will not be counted in
the total number of tests and its completion status will be 'Disabled'.

diff --git a/Help/manual/cmake-properties.7.rst 
b/Help/manual/cmake-properties.7.rst
index 9967d00..072d7c5 100644
--- a/Help/manual/cmake-properties.7.rst
+++ b/Help/manual/cmake-properties.7.rst
@@ -325,6 +325,7 @@ Properties on Tests
/prop_test/ATTACHED_FILES
/prop_test/COST
/prop_test/DEPENDS
+   /prop_test/DISABLED
/prop_test/ENVIRONMENT
/prop_test/FAIL_REGULAR_EXPRESSION
/prop_test/FIXTURES_CLEANUP
diff --git a/Help/prop_test/DISABLED.rst b/Help/prop_test/DISABLED.rst
new file mode 100644
index 000..c18ae7f
--- /dev/null
+++ b/Help/prop_test/DISABLED.rst
@@ -0,0 +1,15 @@
+DISABLED
+
+
+If set to true, the test will be skipped and its status will be 'Not Run'. A
+DISABLED test will not be counted in the total number of tests and its
+completion status will be reported to CDash as 'Disabled'.
+
+A DISABLED test does not participate in test fixture dependency resolution.
+If a DISABLED test has fixture requirements defined in its
+:prop_test:`FIXTURES_REQUIRED` property, it will not cause setup or cleanup
+tests for those fixtures to be added to the test set.
+
+If a test with the :prop_test:`FIXTURES_SETUP` property set is DISABLED, the
+fixture behavior will be as though that setup test was passing and any test
+case requiring that fixture will still run.
diff --git a/Help/release/dev/ctest-disable-tests.rst 
b/Help/release/dev/ctest-disable-tests.rst
new file mode 100644
index 000..9208f0c
--- /dev/null
+++ b/Help/release/dev/ctest-disable-tests.rst
@@ -0,0 +1,5 @@
+ctest-disable-tests
+---
+
+* A :prop_test:`DISABLED` test property was added to mark tests that
+  are configured but explicitly disabled so they do not run.
diff --git a/Source/CTest/cmCTestMultiProcessHandler.cxx 
b/Source/CTest/cmCTestMultiProcessHandler.cxx
index ff465ab..2d4726c 100644
--- a/Source/CTest/cmCTestMultiProcessHandler.cxx
+++ b/Source/CTest/cmCTestMultiProcessHandler.cxx
@@ -163,7 +163,9 @@ void cmCTestMultiProcessHandler::StartTestProcess(int test)
 this->TestRunningMap[test] = false;
 this->RunningCount -= GetProcessorsUsed(test);
 testRun->EndTest(this->Completed, this->Total, false);
-this->Failed->push_back(this->Properties[test]->Name);
+if (!this->Properties[test]->Disabled) {
+  this->Failed->push_back(this->Properties[test]->Name);
+}
 delete testRun;
   }
 }
diff --git a/Source/CTest/cmCTestRunTest.cxx b/Source/CTest/cmCTestRunTest.cxx
index be2b59e..94aa4bd 100644
--- a/Source/CTest/cmCTestRunTest.cxx
+++ b/Source/CTest/cmCTestRunTest.cxx
@@ -256,6 +256,8 @@ bool cmCTestRunTest::EndTest(size_t completed, size_t 
total, bool started)
 cmCTestLog(this->CTest, HANDLER_OUTPUT, "Other");
 this->TestResult.Status = cmCTestTestHandler::OTHER_FAULT;
 }
+  } else if ("Disabled" == this->TestResult.CompletionStatus) {
+cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Not Run (Disabled) ");
   } else // cmsysProcess_State_Error
   {
 cmCTestLog(this->CTest, HANDLER_OUTPUT, "***Not Run ");
@@ -416,6 +418,24 @@ bool cmCTestRunTest::StartTest(size_t total)
<< this->TestProperties->Index << ": "
<< this->TestProperties->Name << std::endl);
   

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-620-g4f7e913

[Kitware Robot]

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

The branch, next has been updated
  discards  70de6381a92d919c050e2067c54a0943db2c493f (commit)
  discards  fcd081d0e83a0d9e681e91ecadbfbb966f611856 (commit)
   via  4f7e91331af6c356e91cf01132e2a82cea4bce4a (commit)
   via  331e44eb8c922143f7956d000bc561c021a16e76 (commit)
   via  6a5a214f4383fbe3dd6de4747aba43088701 (commit)
   via  d4a995750a1e3101f943a0d2e91fc9688f5e23f7 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (70de6381a92d919c050e2067c54a0943db2c493f)
\
 N -- N -- N (4f7e91331af6c356e91cf01132e2a82cea4bce4a)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f7e91331af6c356e91cf01132e2a82cea4bce4a
commit 4f7e91331af6c356e91cf01132e2a82cea4bce4a
Merge: 331e44e 496b845
Author: Brad King 
AuthorDate: Wed Mar 29 13:23:21 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 09:25:52 2017 -0400

Stage topic 'FindBoost-1.64-deps'

Topic-id: 23283
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/629


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=331e44eb8c922143f7956d000bc561c021a16e76
commit 331e44eb8c922143f7956d000bc561c021a16e76
Merge: 6a5a214 8e8f111
Author: Domen Vrankar 
AuthorDate: Wed Mar 29 06:21:41 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 09:25:51 2017 -0400

Stage topic 'cmake-file-install-symlink-on-nonexistng-path'

Topic-id: 23338
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/642


---

Summary of changes:


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

[Cmake-commits] CMake branch, master, updated. v3.8.0-rc3-613-g6a5a214

[Kitware Robot]

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

The branch, master has been updated
   via  6a5a214f4383fbe3dd6de4747aba43088701 (commit)
   via  d4a995750a1e3101f943a0d2e91fc9688f5e23f7 (commit)
  from  6dc7262bf77f551a7f3c36d7ca3023c63ef20af8 (commit)

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

- Log -
---

Summary of changes:


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

[Cmake-commits] CMake branch, release, updated. v3.8.0-rc3-18-gd4a9957

[Kitware Robot]

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

The branch, release has been updated
   via  d4a995750a1e3101f943a0d2e91fc9688f5e23f7 (commit)
   via  fff34934e70da77c359e47c53ffd04701bcd7611 (commit)
   via  79a915383fd0c0e55bf0ca5fe5b3cf07d1823aa7 (commit)
   via  c77194ec471dd4f039c0c30e05f0b519ab44bc14 (commit)
   via  1449f6f63d09f21203b36b3485dd3eb60c73ac17 (commit)
   via  8a619e8c85def632e9e7938fc5a3a36bb22f46ff (commit)
  from  85abc5f5aa5f8afbca88e7b3e1c919db49756ecb (commit)

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

- Log -
---

Summary of changes:
 Modules/CMakeRCInformation.cmake   |   17 -
 Modules/Platform/Windows-MSVC.cmake|3 +++
 Source/cmIDEOptions.cxx|5 +
 Source/cmIDEOptions.h  |2 ++
 Source/cmVisualStudio10TargetGenerator.cxx |   12 +++-
 Source/cmVisualStudioGeneratorOptions.cxx  |5 -
 6 files changed, 37 insertions(+), 7 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-618-g70de638

[Kitware Robot]

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

The branch, next has been updated
  discards  f0932bf2b802983f5c6b72c03fbd321bfeb0b6a6 (commit)
  discards  ccd7ef0b1fafe7581cb110702288cde898e18418 (commit)
  discards  84804eb5b3f33d97f3ecb5902a5df280ec2d4f9e (commit)
  discards  2cc0ea8d610b1b88b4494d0b39da1d6f848758ef (commit)
  discards  62fe278118632236b3adcdbc0717e9f0088d331d (commit)
   via  70de6381a92d919c050e2067c54a0943db2c493f (commit)
   via  fcd081d0e83a0d9e681e91ecadbfbb966f611856 (commit)
   via  6dc7262bf77f551a7f3c36d7ca3023c63ef20af8 (commit)
   via  4a6a27ad85a4be666a3bb4260105a54ba1cea0eb (commit)
   via  2b9086d26614787bbc47b8ee47514583f6814e5d (commit)
   via  ece20f7ae84db12b4ba95768e6aa5cc7e8832585 (commit)
   via  496b845a1e43117d31f33490f14215f8c94ab15d (commit)
   via  8352de538725f292fea20f54efc10ead173ee3b4 (commit)
   via  9defe9d63a44d99dadd440b64721f7d518dd31b6 (commit)
   via  eb69cd94446c9e3ce2debf9d1260a6cfad851a1f (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (f0932bf2b802983f5c6b72c03fbd321bfeb0b6a6)
\
 N -- N -- N (70de6381a92d919c050e2067c54a0943db2c493f)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=70de6381a92d919c050e2067c54a0943db2c493f
commit 70de6381a92d919c050e2067c54a0943db2c493f
Merge: fcd081d 496b845
Author: Brad King 
AuthorDate: Wed Mar 29 13:23:21 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 09:23:23 2017 -0400

Stage topic 'FindBoost-1.64-deps'

Topic-id: 23283
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/629


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fcd081d0e83a0d9e681e91ecadbfbb966f611856
commit fcd081d0e83a0d9e681e91ecadbfbb966f611856
Merge: 6dc7262 8e8f111
Author: Domen Vrankar 
AuthorDate: Wed Mar 29 06:21:41 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 09:15:05 2017 -0400

Stage topic 'cmake-file-install-symlink-on-nonexistng-path'

Topic-id: 23338
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/642


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=496b845a1e43117d31f33490f14215f8c94ab15d
commit 496b845a1e43117d31f33490f14215f8c94ab15d
Author: Roger Leigh 
AuthorDate: Sat Mar 25 22:26:31 2017 +
Commit: Brad King 
CommitDate: Tue Mar 28 10:23:16 2017 -0400

FindBoost: Add numpy dependency for 1.63

Note that 1.63 is missing the needed autolink information, so this is
a manual addition.

Fixes: #16612

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index b1d90c4..8b21c84 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -738,6 +738,7 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 set(_Boost_MATH_DEPENDENCIES math_c99 math_c99f math_c99l math_tr1 
math_tr1f math_tr1l atomic)
 set(_Boost_MPI_DEPENDENCIES serialization)
 set(_Boost_MPI_PYTHON_DEPENDENCIES python mpi serialization)
+set(_Boost_NUMPY_DEPENDENCIES python)
 set(_Boost_RANDOM_DEPENDENCIES system)
 set(_Boost_THREAD_DEPENDENCIES chrono system date_time atomic)
 set(_Boost_WAVE_DEPENDENCIES filesystem system serialization thread chrono 
date_time atomic)

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8352de538725f292fea20f54efc10ead173ee3b4
commit 8352de538725f292fea20f54efc10ead173ee3b4
Author: Roger Leigh 
AuthorDate: Sat Mar 25 22:24:22 2017 +
Commit: Brad King 
CommitDate: Tue Mar 28 10:23:11 2017 -0400

FindBoost: Update 1.64 dependencies using 1.64 beta1

diff --git a/Modules/FindBoost.cmake b/Modules/FindBoost.cmake
index ef8435e..b1d90c4 100644
--- a/Modules/FindBoost.cmake
+++ b/Modules/FindBoost.cmake
@@ -746,6 +746,7 @@ function(_Boost_COMPONENT_DEPENDENCIES component _ret)
 set(_Boost_CHRONO_DEPENDENCIES system)
 set(_Boost_CONTEXT_DEPENDENCIES thread chrono system date_time)
 set(_Boost_COROUTINE_DEPENDENCIES context system)
+set(_Boost_COROUTINE2_DEPENDENCIES context fiber thread chrono system 
date_time)
  

[Cmake-commits] CMake branch, master, updated. v3.8.0-rc3-611-g6dc7262

[Kitware Robot]

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

The branch, master has been updated
   via  6dc7262bf77f551a7f3c36d7ca3023c63ef20af8 (commit)
   via  4a6a27ad85a4be666a3bb4260105a54ba1cea0eb (commit)
   via  2b9086d26614787bbc47b8ee47514583f6814e5d (commit)
   via  ece20f7ae84db12b4ba95768e6aa5cc7e8832585 (commit)
   via  62b85c940622bdcc25964ed95bec68a562de59ee (commit)
   via  fff34934e70da77c359e47c53ffd04701bcd7611 (commit)
   via  79a915383fd0c0e55bf0ca5fe5b3cf07d1823aa7 (commit)
   via  c77194ec471dd4f039c0c30e05f0b519ab44bc14 (commit)
   via  1449f6f63d09f21203b36b3485dd3eb60c73ac17 (commit)
   via  8a619e8c85def632e9e7938fc5a3a36bb22f46ff (commit)
   via  7a411dfbf6d9987869fd39e57f38f6a9c3d548aa (commit)
   via  cdd2875ad2f1d5e0b0bc92ca1dff4f0c14d3424b (commit)
   via  e9c5505bf9c51c34dea703b86a293ff04475db54 (commit)
  from  3e4e6594da5668d7f80a1192594d9ee4fc790eb8 (commit)

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

- Log -
---

Summary of changes:
 Modules/CMakeRCInformation.cmake   |   17 -
 Modules/Platform/Windows-MSVC.cmake|3 +++
 Source/cmIDEOptions.cxx|5 +
 Source/cmIDEOptions.h  |2 ++
 Source/cmLocalVisualStudio7Generator.cxx   |   10 ++
 Source/cmVisualStudio10TargetGenerator.cxx |   12 +++-
 Source/cmVisualStudioGeneratorOptions.cxx  |5 -
 Source/kwsys/FStream.hxx.in|4 ++--
 Utilities/Sphinx/conf.py.in|   20 
 9 files changed, 65 insertions(+), 13 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-634-gaf34df7

[Kitware Robot]

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

The branch, next has been updated
   via  af34df7415c288c64b816938992e5b9ecfe5d312 (commit)
   via  48cfb295a2810e541bd286f352d77d840be345f7 (commit)
   via  90bb5f64a48265cee1ec6c1f57c5ac57b632fd68 (commit)
   via  ab5f4e81f305e48234546583a2c8c4334cea78f0 (commit)
   via  f8ed8bef84dcd4746ee223bd34f05b7c995cb363 (commit)
   via  8647c6cd6825764b8cd69828c185bad14ffc8a7e (commit)
   via  21a6ed49f2d06982e080eb5fc2f0a7d1c2ea0846 (commit)
   via  a2275bdd636987abcf002fad000c4f02d615d219 (commit)
  from  c9728d7adef051ae309d8dfa3cce1f505936e4cf (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=af34df7415c288c64b816938992e5b9ecfe5d312
commit af34df7415c288c64b816938992e5b9ecfe5d312
Merge: c9728d7 48cfb29
Author: Daniel Pfeifer 
AuthorDate: Wed Mar 29 17:17:18 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 13:17:21 2017 -0400

Stage topic 'iwyu'

Topic-id: 23274
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/626


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48cfb295a2810e541bd286f352d77d840be345f7
commit 48cfb295a2810e541bd286f352d77d840be345f7
Author: Daniel Pfeifer 
AuthorDate: Sat Mar 25 00:03:48 2017 +0100
Commit: Daniel Pfeifer 
CommitDate: Wed Mar 29 18:48:48 2017 +0200

cmFortranParser: remove unnecessary typedef

diff --git a/Source/cmFortranParser.h b/Source/cmFortranParser.h
index e8273fb..024b00a 100644
--- a/Source/cmFortranParser.h
+++ b/Source/cmFortranParser.h
@@ -54,8 +54,7 @@ void cmFortranParser_RuleElse(cmFortranParser* parser);
 void cmFortranParser_RuleEndif(cmFortranParser* parser);
 
 /* Define the parser stack element type.  */
-typedef union cmFortran_yystype_u cmFortran_yystype;
-union cmFortran_yystype_u
+struct cmFortran_yystype
 {
   char* string;
 };

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=90bb5f64a48265cee1ec6c1f57c5ac57b632fd68
commit 90bb5f64a48265cee1ec6c1f57c5ac57b632fd68
Author: Daniel Pfeifer 
AuthorDate: Sat Mar 25 00:00:29 2017 +0100
Commit: Daniel Pfeifer 
CommitDate: Wed Mar 29 18:48:47 2017 +0200

cmCommandArgumentParserHelper: remove unnecessary include

diff --git a/Source/cmCommandArgumentParserHelper.cxx 
b/Source/cmCommandArgumentParserHelper.cxx
index 2d66344..1222d5a 100644
--- a/Source/cmCommandArgumentParserHelper.cxx
+++ b/Source/cmCommandArgumentParserHelper.cxx
@@ -2,8 +2,6 @@
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmCommandArgumentParserHelper.h"
 
-#include 
-
 #include "cmCommandArgumentLexer.h"
 #include "cmMakefile.h"
 #include "cmState.h"

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ab5f4e81f305e48234546583a2c8c4334cea78f0
commit ab5f4e81f305e48234546583a2c8c4334cea78f0
Author: Daniel Pfeifer 
AuthorDate: Fri Mar 24 23:59:53 2017 +0100
Commit: Daniel Pfeifer 
CommitDate: Wed Mar 29 18:48:47 2017 +0200

cmFortranParserImpl: remove unnecessary include

diff --git a/Source/cmFortranParserImpl.cxx b/Source/cmFortranParserImpl.cxx
index 1a5e6c5..1abe673 100644
--- a/Source/cmFortranParserImpl.cxx
+++ b/Source/cmFortranParserImpl.cxx
@@ -1,7 +1,6 @@
 /* Distributed under the OSI-approved BSD 3-Clause License.  See accompanying
file Copyright.txt or https://cmake.org/licensing for details.  */
 #include "cmFortranParser.h"
-#include "cmFortranLexer.h"
 #include "cmSystemTools.h"
 
 #include 

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f8ed8bef84dcd4746ee223bd34f05b7c995cb363
commit f8ed8bef84dcd4746ee223bd34f05b7c995cb363
Author: Daniel Pfeifer 
AuthorDate: Fri Mar 24 23:58:37 2017 +0100
Commit: Daniel Pfeifer 
CommitDate: Wed Mar 29 18:48:47 2017 +0200

testEncoding: use cmsys::ifstream

diff --git a/Tests/CMakeLib/testEncoding.cxx b/Tests/CMakeLib/testEncoding.cxx
index 20ba9e3..403c896 100644
--- a/Tests/CMakeLib/testEncoding.cxx
+++ b/Tests/CMakeLib/testEncoding.cxx
@@ -1,4 +1,4 @@
-#include 
+#include 
 #include 
 #include 
 
@@ -39,7 +39,7 @@ int main(int argc, char* argv[])
 setEncoding(consoleOut, CP_OEMCP);
   } // else AUTO
 #endif
-  std::ifstream file(argv[2]);
+  cmsys::ifstream file(argv[2]);
   if (!file.is_open()) {
 std::cout << "Failed to open file: " << argv[2] << std::endl;
 return 2;

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8647c6cd6825764b8cd69828c185bad14ffc8a7e

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-636-g0e71929

[Kitware Robot]

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

The branch, next has been updated
   via  0e71929e43279e3a806d476786a58d1c4e948083 (commit)
   via  5695558f4a5f0d68cd1c200258b89d1524ff230f (commit)
  from  af34df7415c288c64b816938992e5b9ecfe5d312 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0e71929e43279e3a806d476786a58d1c4e948083
commit 0e71929e43279e3a806d476786a58d1c4e948083
Merge: af34df7 5695558
Author: Brad King 
AuthorDate: Wed Mar 29 17:31:32 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 13:31:52 2017 -0400

Stage topic 'sdcc-compiler-id'

Topic-id: 23359
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/644


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5695558f4a5f0d68cd1c200258b89d1524ff230f
commit 5695558f4a5f0d68cd1c200258b89d1524ff230f
Author: Brad King 
AuthorDate: Wed Mar 29 11:51:31 2017 -0400
Commit: Brad King 
CommitDate: Wed Mar 29 13:21:49 2017 -0400

SDCC: Fix identification of current sdcc compiler

The sdcc compiler no longer defines the `SDCC` preprocessor macro.
Instead `__SDCC_VERSION_MAJOR` and similar component-wise macros are
defined.  Use them instead if defined.

Issue: #16746

diff --git a/Modules/Compiler/SDCC-C-DetermineCompiler.cmake 
b/Modules/Compiler/SDCC-C-DetermineCompiler.cmake
index 1d7dd78..4c70c5e 100644
--- a/Modules/Compiler/SDCC-C-DetermineCompiler.cmake
+++ b/Modules/Compiler/SDCC-C-DetermineCompiler.cmake
@@ -1,10 +1,16 @@
 
 # sdcc, the small devices C compiler for embedded systems,
 #   http://sdcc.sourceforge.net  */
-set(_compiler_id_pp_test "defined(SDCC)")
+set(_compiler_id_pp_test "defined(__SDCC_VERSION_MAJOR) || defined(SDCC)")
 
 set(_compiler_id_version_compute "
+# if defined(__SDCC_VERSION_MAJOR)
+#  define COMPILER_VERSION_MAJOR @MACRO_DEC@(__SDCC_VERSION_MAJOR)
+#  define COMPILER_VERSION_MINOR @MACRO_DEC@(__SDCC_VERSION_MINOR)
+#  define COMPILER_VERSION_PATCH @MACRO_DEC@(__SDCC_VERSION_PATCH)
+# else
   /* SDCC = VRP */
 #  define COMPILER_VERSION_MAJOR @MACRO_DEC@(SDCC/100)
 #  define COMPILER_VERSION_MINOR @MACRO_DEC@(SDCC/10 % 10)
-#  define COMPILER_VERSION_PATCH @MACRO_DEC@(SDCC% 10)")
+#  define COMPILER_VERSION_PATCH @MACRO_DEC@(SDCC% 10)
+# endif")

---

Summary of changes:
 Modules/Compiler/SDCC-C-DetermineCompiler.cmake |   10 --
 1 file changed, 8 insertions(+), 2 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-623-gbdc5141

[Kitware Robot]

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

The branch, next has been updated
   via  bdc5141f31e33ab4516a46fcee6e612baa583f84 (commit)
   via  77139e320c8ec7f92e1298cc57fea7276faceb12 (commit)
   via  c03141c04cededf6bf31d51627cd8b29c7668495 (commit)
  from  4f7e91331af6c356e91cf01132e2a82cea4bce4a (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bdc5141f31e33ab4516a46fcee6e612baa583f84
commit bdc5141f31e33ab4516a46fcee6e612baa583f84
Merge: 4f7e913 77139e3
Author: Brad King 
AuthorDate: Wed Mar 29 13:39:21 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 09:39:24 2017 -0400

Stage topic '16742-swift-3.0'

Topic-id: 23323
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/638


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=77139e320c8ec7f92e1298cc57fea7276faceb12
commit 77139e320c8ec7f92e1298cc57fea7276faceb12
Author: Gregor Jasny 
AuthorDate: Wed Mar 29 15:32:01 2017 +0200
Commit: Gregor Jasny 
CommitDate: Wed Mar 29 15:36:05 2017 +0200

Swift: Simplify mixed test case to make it version agnostic

Issue: #16742

diff --git a/Tests/SwiftMix/ObjCMain.m b/Tests/SwiftMix/ObjCMain.m
index 5a8700c..20f0bf1 100644
--- a/Tests/SwiftMix/ObjCMain.m
+++ b/Tests/SwiftMix/ObjCMain.m
@@ -1,10 +1,4 @@
 #import "SwiftMix-Swift.h"
 int ObjCMain(int argc, char const* const argv[]) {
-  if ([SwiftMainClass respondsToSelector:@selector(SwiftMain:argv:)]) {
-return [SwiftMainClass SwiftMain:argc argv:argv];
-  }
-  if ([SwiftMainClass respondsToSelector:@selector(SwiftMainWithArgc:argv:)]) {
-return [SwiftMainClass SwiftMainWithArgc:argc argv:argv];
-  }
-  return -1;
+  return [SwiftMainClass SwiftMain];
 }
diff --git a/Tests/SwiftMix/SwiftMain.swift b/Tests/SwiftMix/SwiftMain.swift
index 921439a..a4a0a62 100644
--- a/Tests/SwiftMix/SwiftMain.swift
+++ b/Tests/SwiftMix/SwiftMain.swift
@@ -1,19 +1,8 @@
 import Foundation
 
 @objc class SwiftMainClass : NSObject {
-  class func SwiftMain(argc:Int, argv:UnsafePointer) -> 
Int32 {
-dump("argc: \(argc)")
-#if swift(>=3.0)
-for i in 0 ..< argc {
-  let argi = String(cString:argv[i]);
-  dump("arg[\(i)]: \(argi)");
-}
-#else
-for (var i = 0; i < argc; ++i) {
-  let argi = String.fromCString(argv[i])
-  dump("arg[\(i)]: \(argi)");
-}
-#endif
+  class func SwiftMain() -> Int32 {
+dump("Hello World!");
 return 0;
   }
 }

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c03141c04cededf6bf31d51627cd8b29c7668495
commit c03141c04cededf6bf31d51627cd8b29c7668495
Author: Gregor Jasny 
AuthorDate: Tue Mar 28 16:04:02 2017 +0200
Commit: Brad King 
CommitDate: Tue Mar 28 16:06:29 2017 -0400

Swift: Default to Swift 3.0 with Xcode 8.3 and later

Xcode 8.3 has dropped support for Swift 2.3 so that compiler and
feature detection failed.

Closes #16742

diff --git a/Modules/CMakeDetermineCompilerId.cmake 
b/Modules/CMakeDetermineCompilerId.cmake
index bb34de5..c41a986 100644
--- a/Modules/CMakeDetermineCompilerId.cmake
+++ b/Modules/CMakeDetermineCompilerId.cmake
@@ -269,7 +269,13 @@ Id flags: ${testflags} 
${CMAKE_${lang}_COMPILER_ID_FLAGS_ALWAYS}
   set(id_toolset "")
 endif()
 if("${lang}" STREQUAL "Swift")
-  set(id_lang_version "SWIFT_VERSION = 2.3;")
+  if(CMAKE_Swift_LANGUAGE_VERSION)
+set(id_lang_version "SWIFT_VERSION = ${CMAKE_Swift_LANGUAGE_VERSION};")
+  elseif(XCODE_VERSION VERSION_GREATER_EQUAL 8.3)
+set(id_lang_version "SWIFT_VERSION = 3.0;")
+  else()
+set(id_lang_version "SWIFT_VERSION = 2.3;")
+  endif()
 else()
   set(id_lang_version "")
 endif()
diff --git a/Source/cmGlobalXCodeGenerator.cxx 
b/Source/cmGlobalXCodeGenerator.cxx
index 8627cf2..dd771b1 100644
--- a/Source/cmGlobalXCodeGenerator.cxx
+++ b/Source/cmGlobalXCodeGenerator.cxx
@@ -3075,10 +3075,14 @@ bool cmGlobalXCodeGenerator::CreateXCodeObjects(
 this->CreateString(this->GeneratorToolset));
   }
   if (this->GetLanguageEnabled("Swift")) {
-std::string swiftVersion = "2.3";
+std::string swiftVersion;
 if (const char* vers = this->CurrentMakefile->GetDefinition(
   "CMAKE_Swift_LANGUAGE_VERSION")) {
   swiftVersion = vers;
+} else if (this->XcodeVersion >= 83) {
+  swiftVersion = "3.0";
+} else {
+  swiftVersion = "2.3";
 }
 buildSettings->AddAttribute("SWIFT_VERSION",
   

[cmake-developers] Email addresses of Mantis bug reporters

[Gregor Jasny via cmake-developers]

Hello,

while walking through old bug reports contacting the reporters by email
would be helpful sometimes. Is there a way for me access this
information in Mantis?

Thanks,
Gregor
-- 

Powered by www.kitware.com

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

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

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

Visit other Kitware 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] Email addresses of Mantis bug reporters

[Brad King]

On 03/29/2017 03:59 PM, Gregor Jasny via cmake-developers wrote:
> while walking through old bug reports contacting the reporters by email
> would be helpful sometimes. Is there a way for me access this
> information in Mantis?

I don't think that information is publicly accessible in Mantis.
Contact me via private email with the user names and I'll see if
I can find the emails.

Thanks,
-Brad

-- 

Powered by www.kitware.com

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

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

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

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

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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-638-gfcb2d3e

[Kitware Robot]

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

The branch, next has been updated
   via  fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541 (commit)
   via  01a8a201a7549369ea331516f8c6caa459074a8a (commit)
  from  0e71929e43279e3a806d476786a58d1c4e948083 (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541
commit fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541
Merge: 0e71929 01a8a20
Author: Brad King 
AuthorDate: Wed Mar 29 20:27:58 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 16:28:06 2017 -0400

Stage topic '10749-aix-version'

Topic-id: 23363
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/645


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=01a8a201a7549369ea331516f8c6caa459074a8a
commit 01a8a201a7549369ea331516f8c6caa459074a8a
Author: Gregor Jasny 
AuthorDate: Wed Mar 29 21:14:36 2017 +0200
Commit: Gregor Jasny 
CommitDate: Wed Mar 29 21:20:23 2017 +0200

AIX: Properly detect host system version

CMakeDetermineSystem.cmake uses "uname -r" to get
CMAKE_HOST_SYSTEM_VERSION on AIX. AIX uses "uname -v" for the
major version and "uname -r" for the minor version.

Thanks to Chris Taylor for the suggested patch.

Closes #10749

diff --git a/Modules/CMakeDetermineSystem.cmake 
b/Modules/CMakeDetermineSystem.cmake
index f34ec5d..20dcf1b 100644
--- a/Modules/CMakeDetermineSystem.cmake
+++ b/Modules/CMakeDetermineSystem.cmake
@@ -35,7 +35,15 @@
 if(CMAKE_HOST_UNIX)
   find_program(CMAKE_UNAME uname /bin /usr/bin /usr/local/bin )
   if(CMAKE_UNAME)
-exec_program(${CMAKE_UNAME} ARGS -r OUTPUT_VARIABLE 
CMAKE_HOST_SYSTEM_VERSION)
+if(CMAKE_HOST_SYSTEM_NAME STREQUAL "AIX")
+  exec_program(${CMAKE_UNAME} ARGS -v OUTPUT_VARIABLE 
_CMAKE_HOST_SYSTEM_MAJOR_VERSION)
+  exec_program(${CMAKE_UNAME} ARGS -r OUTPUT_VARIABLE 
_CMAKE_HOST_SYSTEM_MINOR_VERSION)
+  set(CMAKE_HOST_SYSTEM_VERSION 
"${_CMAKE_HOST_SYSTEM_MAJOR_VERSION}.${_CMAKE_HOST_SYSTEM_MINOR_VERSION}")
+  unset(_CMAKE_HOST_SYSTEM_MAJOR_VERSION)
+  unset(_CMAKE_HOST_SYSTEM_MINOR_VERSION)
+else()
+  exec_program(${CMAKE_UNAME} ARGS -r OUTPUT_VARIABLE 
CMAKE_HOST_SYSTEM_VERSION)
+endif()
 if(CMAKE_HOST_SYSTEM_NAME MATCHES "Linux|CYGWIN.*|Darwin|^GNU$")
   exec_program(${CMAKE_UNAME} ARGS -m OUTPUT_VARIABLE 
CMAKE_HOST_SYSTEM_PROCESSOR
 RETURN_VALUE val)

---

Summary of changes:
 Modules/CMakeDetermineSystem.cmake |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-613-gf0932bf

[Kitware Robot]

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

The branch, next has been updated
  discards  6543b1b9b1109f14292a3a63546f44ab22e0ed48 (commit)
  discards  ae2232a4e86e21e52f73c709feb729bd94271dca (commit)
  discards  dc5ea8ee24a81a7b5e9a05232c00a4e85528641c (commit)
   via  f0932bf2b802983f5c6b72c03fbd321bfeb0b6a6 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (6543b1b9b1109f14292a3a63546f44ab22e0ed48)
\
 N -- N -- N (f0932bf2b802983f5c6b72c03fbd321bfeb0b6a6)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=f0932bf2b802983f5c6b72c03fbd321bfeb0b6a6
commit f0932bf2b802983f5c6b72c03fbd321bfeb0b6a6
Merge: ccd7ef0 8e8f111
Author: Domen Vrankar 
AuthorDate: Wed Mar 29 06:21:41 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 09:03:04 2017 -0400

Stage topic 'cmake-file-install-symlink-on-nonexistng-path'

Topic-id: 23338
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/642


---

Summary of changes:
 Modules/CMakeDetermineCompilerId.cmake |8 +---
 Source/cmGlobalXCodeGenerator.cxx  |6 +-
 Tests/SwiftMix/ObjCMain.m  |8 +---
 Tests/SwiftMix/SwiftMain.swift |7 ---
 4 files changed, 3 insertions(+), 26 deletions(-)


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

[Cmake-commits] CMake branch, nightly, updated. v3.8.0-rc3-638-gfcb2d3e

[Kitware Robot]

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

The branch, nightly has been updated
  discards  896e195588bde813ad6e0cc8af7fe1594d37907c (commit)
  discards  dc5ea8ee24a81a7b5e9a05232c00a4e85528641c (commit)
  discards  10a48e620ee872e32642ed5ad1e993776be2a694 (commit)
  discards  eb3978b6688c4233a42b890ebc26e278940942b1 (commit)
  discards  bc35c1bb7b1175e79dd8bc177fb47f8367fae26b (commit)
  discards  3b32fdc5d1530368b5b05d009f59bca79759d1c1 (commit)
   via  fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541 (commit)
   via  01a8a201a7549369ea331516f8c6caa459074a8a (commit)
   via  0e71929e43279e3a806d476786a58d1c4e948083 (commit)
   via  5695558f4a5f0d68cd1c200258b89d1524ff230f (commit)
   via  af34df7415c288c64b816938992e5b9ecfe5d312 (commit)
   via  48cfb295a2810e541bd286f352d77d840be345f7 (commit)
   via  90bb5f64a48265cee1ec6c1f57c5ac57b632fd68 (commit)
   via  ab5f4e81f305e48234546583a2c8c4334cea78f0 (commit)
   via  f8ed8bef84dcd4746ee223bd34f05b7c995cb363 (commit)
   via  8647c6cd6825764b8cd69828c185bad14ffc8a7e (commit)
   via  21a6ed49f2d06982e080eb5fc2f0a7d1c2ea0846 (commit)
   via  a2275bdd636987abcf002fad000c4f02d615d219 (commit)
   via  c9728d7adef051ae309d8dfa3cce1f505936e4cf (commit)
   via  b070947dffd141d50227c59feed4c3d784b39157 (commit)
   via  bdc5141f31e33ab4516a46fcee6e612baa583f84 (commit)
   via  77139e320c8ec7f92e1298cc57fea7276faceb12 (commit)
   via  4f7e91331af6c356e91cf01132e2a82cea4bce4a (commit)
   via  331e44eb8c922143f7956d000bc561c021a16e76 (commit)
   via  6a5a214f4383fbe3dd6de4747aba43088701 (commit)
   via  d4a995750a1e3101f943a0d2e91fc9688f5e23f7 (commit)
   via  6dc7262bf77f551a7f3c36d7ca3023c63ef20af8 (commit)
   via  4a6a27ad85a4be666a3bb4260105a54ba1cea0eb (commit)
   via  2b9086d26614787bbc47b8ee47514583f6814e5d (commit)
   via  ece20f7ae84db12b4ba95768e6aa5cc7e8832585 (commit)
   via  3e4e6594da5668d7f80a1192594d9ee4fc790eb8 (commit)
   via  8e8f1118b947905e0e881ea3d9cc881f5fdce89d (commit)
   via  c03141c04cededf6bf31d51627cd8b29c7668495 (commit)
   via  496b845a1e43117d31f33490f14215f8c94ab15d (commit)
   via  8352de538725f292fea20f54efc10ead173ee3b4 (commit)
   via  9defe9d63a44d99dadd440b64721f7d518dd31b6 (commit)
   via  eb69cd94446c9e3ce2debf9d1260a6cfad851a1f (commit)
   via  42c68aadf81a47d563392421636e14ef77644e03 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (896e195588bde813ad6e0cc8af7fe1594d37907c)
\
 N -- N -- N (fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

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

- Log -
---

Summary of changes:
 Help/manual/cmake-properties.7.rst |1 +
 Help/manual/cmake.1.rst|3 +
 Help/prop_test/DISABLED.rst|   15 
 Help/release/dev/ctest-disable-tests.rst   |5 ++
 Modules/CMakeDetermineSystem.cmake |   10 ++-
 Modules/Compiler/SDCC-C-DetermineCompiler.cmake|   10 ++-
 Modules/FindBoost.cmake|4 +
 Source/CMakeVersion.cmake  |2 +-
 Source/CTest/cmCTestMultiProcessHandler.cxx|4 +-
 Source/CTest/cmCTestRunTest.cxx|   31 ++-
 Source/CTest/cmCTestTestHandler.cxx|   65 +++---
 Source/CTest/cmCTestTestHandler.h  |1 +
 Source/cmCommandArgumentParserHelper.cxx   |2 -
 Source/cmFileCommand.cxx   |6 +-
 Source/cmFortranParser.h   |3 +-
 Source/cmFortranParserImpl.cxx |1 -
 Tests/CMakeLib/testEncoding.cxx|6 +-
 Tests/RunCMake/CMakeLists.txt  |1 +
 .../RunCMake/ctest_disabled_test/CMakeLists.txt.in |6 ++
 .../ctest_disabled_test/CTestConfig.cmake.in   |1 +
 .../DisableAllTests-result.txt}|0
 .../DisableAllTests-stderr.txt}|0
 .../ctest_disabled_test/DisableAllTests-stdout.txt |2 +
 .../DisableCleanupTest-stdout.txt  |   11 +++
 .../DisableFailingTest-stdout.txt 

[Cmake-commits] CMake branch, nightly-master, updated. v3.8.0-rc3-613-g6a5a214

[Kitware Robot]

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

The branch, nightly-master has been updated
   via  6a5a214f4383fbe3dd6de4747aba43088701 (commit)
   via  d4a995750a1e3101f943a0d2e91fc9688f5e23f7 (commit)
   via  6dc7262bf77f551a7f3c36d7ca3023c63ef20af8 (commit)
   via  4a6a27ad85a4be666a3bb4260105a54ba1cea0eb (commit)
   via  2b9086d26614787bbc47b8ee47514583f6814e5d (commit)
   via  ece20f7ae84db12b4ba95768e6aa5cc7e8832585 (commit)
   via  3e4e6594da5668d7f80a1192594d9ee4fc790eb8 (commit)
   via  62b85c940622bdcc25964ed95bec68a562de59ee (commit)
   via  fff34934e70da77c359e47c53ffd04701bcd7611 (commit)
   via  79a915383fd0c0e55bf0ca5fe5b3cf07d1823aa7 (commit)
   via  c77194ec471dd4f039c0c30e05f0b519ab44bc14 (commit)
   via  1449f6f63d09f21203b36b3485dd3eb60c73ac17 (commit)
   via  8a619e8c85def632e9e7938fc5a3a36bb22f46ff (commit)
   via  7a411dfbf6d9987869fd39e57f38f6a9c3d548aa (commit)
   via  cdd2875ad2f1d5e0b0bc92ca1dff4f0c14d3424b (commit)
   via  e9c5505bf9c51c34dea703b86a293ff04475db54 (commit)
  from  cc4fbda1a9fffd8927de870643f167f066b26bcd (commit)

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

- Log -
---

Summary of changes:
 Modules/CMakeRCInformation.cmake   |   17 -
 Modules/Platform/Windows-MSVC.cmake|3 +++
 Source/CMakeVersion.cmake  |2 +-
 Source/cmIDEOptions.cxx|5 +
 Source/cmIDEOptions.h  |2 ++
 Source/cmLocalVisualStudio7Generator.cxx   |   10 ++
 Source/cmVisualStudio10TargetGenerator.cxx |   12 +++-
 Source/cmVisualStudioGeneratorOptions.cxx  |5 -
 Source/kwsys/FStream.hxx.in|4 ++--
 Utilities/Sphinx/conf.py.in|   20 
 10 files changed, 66 insertions(+), 14 deletions(-)


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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-639-g8484d6e

[Kitware Robot]

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

The branch, next has been updated
  discards  fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541 (commit)
  discards  0e71929e43279e3a806d476786a58d1c4e948083 (commit)
  discards  af34df7415c288c64b816938992e5b9ecfe5d312 (commit)
  discards  c9728d7adef051ae309d8dfa3cce1f505936e4cf (commit)
  discards  bdc5141f31e33ab4516a46fcee6e612baa583f84 (commit)
  discards  4f7e91331af6c356e91cf01132e2a82cea4bce4a (commit)
  discards  331e44eb8c922143f7956d000bc561c021a16e76 (commit)
   via  8484d6edc18a7f269be41f2f7adca80f2a0c369e (commit)
   via  3ee9f77955119027fa12818738d300dc1a960cec (commit)
   via  abb1f72c377f5a69133ef3dc9ff9f65e9b900e42 (commit)
   via  7f74589f2e9ac77969e79edfc9f325faa066d3a8 (commit)
   via  7e6ce4eca5523c986109093599cf5ba95f81b03c (commit)
   via  9dc40c3713658207ba0ff11ff79c3a12a83619ca (commit)
   via  1cd27c31feef05b7be776758670e3c2f18acbf35 (commit)
   via  f6d802b5bcd201f48c7af47f27ec9e1dd0062171 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (fcb2d3e17b5cfc3c0a98dad59a56e0022ba92541)
\
 N -- N -- N (8484d6edc18a7f269be41f2f7adca80f2a0c369e)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8484d6edc18a7f269be41f2f7adca80f2a0c369e
commit 8484d6edc18a7f269be41f2f7adca80f2a0c369e
Merge: 3ee9f77 01a8a20
Author: Brad King 
AuthorDate: Wed Mar 29 20:27:58 2017 +
Commit: Kitware Robot 
CommitDate: Thu Mar 30 00:01:27 2017 -0400

Stage topic '10749-aix-version'

Topic-id: 23363
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/645


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3ee9f77955119027fa12818738d300dc1a960cec
commit 3ee9f77955119027fa12818738d300dc1a960cec
Merge: abb1f72 5695558
Author: Brad King 
AuthorDate: Wed Mar 29 17:31:32 2017 +
Commit: Kitware Robot 
CommitDate: Thu Mar 30 00:01:27 2017 -0400

Stage topic 'sdcc-compiler-id'

Topic-id: 23359
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/644


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=abb1f72c377f5a69133ef3dc9ff9f65e9b900e42
commit abb1f72c377f5a69133ef3dc9ff9f65e9b900e42
Merge: 7f74589 48cfb29
Author: Daniel Pfeifer 
AuthorDate: Wed Mar 29 17:17:18 2017 +
Commit: Kitware Robot 
CommitDate: Thu Mar 30 00:01:26 2017 -0400

Stage topic 'iwyu'

Topic-id: 23274
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/626


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7f74589f2e9ac77969e79edfc9f325faa066d3a8
commit 7f74589f2e9ac77969e79edfc9f325faa066d3a8
Merge: 7e6ce4e b070947
Author: Brad King 
AuthorDate: Wed Mar 29 14:31:25 2017 +
Commit: Kitware Robot 
CommitDate: Thu Mar 30 00:01:25 2017 -0400

Stage topic 'ctest-disable-tests'

Topic-id: 22988
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/571


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e6ce4eca5523c986109093599cf5ba95f81b03c
commit 7e6ce4eca5523c986109093599cf5ba95f81b03c
Merge: 9dc40c3 77139e3
Author: Brad King 
AuthorDate: Wed Mar 29 13:39:21 2017 +
Commit: Kitware Robot 
CommitDate: Thu Mar 30 00:01:23 2017 -0400

Stage topic '16742-swift-3.0'

Topic-id: 23323
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/638


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9dc40c3713658207ba0ff11ff79c3a12a83619ca
commit 9dc40c3713658207ba0ff11ff79c3a12a83619ca
Merge: 1cd27c3 496b845
Author: Brad King 
AuthorDate: Wed Mar 29 13:23:21 2017 +
Commit: Kitware Robot 
CommitDate: Thu Mar 30 00:01:23 2017 -0400

Stage topic 'FindBoost-1.64-deps'

Topic-id: 23283
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/629


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1cd27c31feef05b7be776758670e3c2f18acbf35
commit 1cd27c31feef05b7be776758670e3c2f18acbf35
Merge: f6d802b 8e8f111
Author: 

[Cmake-commits] CMake branch, master, updated. v3.8.0-rc3-614-gf6d802b

[Kitware Robot]

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

The branch, master has been updated
   via  f6d802b5bcd201f48c7af47f27ec9e1dd0062171 (commit)
  from  6a5a214f4383fbe3dd6de4747aba43088701 (commit)

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

- Log -
---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, next, updated. v3.8.0-rc3-615-g6543b1b

[Kitware Robot]

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

The branch, next has been updated
   via  6543b1b9b1109f14292a3a63546f44ab22e0ed48 (commit)
   via  8e8f1118b947905e0e881ea3d9cc881f5fdce89d (commit)
  from  ae2232a4e86e21e52f73c709feb729bd94271dca (commit)

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

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6543b1b9b1109f14292a3a63546f44ab22e0ed48
commit 6543b1b9b1109f14292a3a63546f44ab22e0ed48
Merge: ae2232a 8e8f111
Author: Domen Vrankar 
AuthorDate: Wed Mar 29 06:21:41 2017 +
Commit: Kitware Robot 
CommitDate: Wed Mar 29 02:22:08 2017 -0400

Stage topic 'cmake-file-install-symlink-on-nonexistng-path'

Topic-id: 23338
Topic-url: https://gitlab.kitware.com/cmake/cmake/merge_requests/642


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8e8f1118b947905e0e881ea3d9cc881f5fdce89d
commit 8e8f1118b947905e0e881ea3d9cc881f5fdce89d
Author: Domen Vrankar 
AuthorDate: Wed Mar 29 00:22:52 2017 +0200
Commit: Domen Vrankar 
CommitDate: Wed Mar 29 00:22:52 2017 +0200

handle non-existing symlink creation locations

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 063aea1..a11e2f9 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -315,6 +315,9 @@ The following ``cmake -E`` commands are available only on 
UNIX:
 ``create_symlink  ``
   Create a symbolic link  naming .
 
+.. note::
+  Path to where  symbolic link will be created has to exist 
beforehand.
+
 Windows-specific Command-Line Tools
 ---
 
diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index 97292f9..7207d34 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -1486,6 +1486,9 @@ bool cmFileCopier::InstallSymlink(const char* fromFile, 
const char* toFile)
 // Remove the destination file so we can always create the symlink.
 cmSystemTools::RemoveFile(toFile);
 
+// Create destination directory if it doesn't exist
+cmSystemTools::MakeDirectory(cmSystemTools::GetFilenamePath(toFile));
+
 // Create the symlink.
 if (!cmSystemTools::CreateSymlink(symlinkTarget, toFile)) {
   std::ostringstream e;
diff --git a/Tests/RunCMake/file/INSTALL-SYMLINK-stdout.txt 
b/Tests/RunCMake/file/INSTALL-SYMLINK-stdout.txt
new file mode 100644
index 000..9fb8e10
--- /dev/null
+++ b/Tests/RunCMake/file/INSTALL-SYMLINK-stdout.txt
@@ -0,0 +1,3 @@
+-- Before Installing
+-- Installing: 
.*/Tests/RunCMake/file/INSTALL-SYMLINK-build/dst/current_dir_symlink
+-- After Installing
diff --git a/Tests/RunCMake/file/INSTALL-SYMLINK.cmake 
b/Tests/RunCMake/file/INSTALL-SYMLINK.cmake
new file mode 100644
index 000..5a4284a
--- /dev/null
+++ b/Tests/RunCMake/file/INSTALL-SYMLINK.cmake
@@ -0,0 +1,13 @@
+set(src "${CMAKE_CURRENT_BINARY_DIR}/src")
+set(dst "${CMAKE_CURRENT_BINARY_DIR}/dst")
+file(REMOVE RECURSE "${src}")
+file(REMOVE RECURSE "${dst}")
+
+file(MAKE_DIRECTORY "${src}")
+execute_process(COMMAND
+  ${CMAKE_COMMAND} -E create_symlink source "${src}/current_dir_symlink")
+
+message(STATUS "Before Installing")
+file(INSTALL FILES "${src}/current_dir_symlink"
+  DESTINATION ${dst} TYPE DIRECTORY)
+message(STATUS "After Installing")
diff --git a/Tests/RunCMake/file/RunCMakeTest.cmake 
b/Tests/RunCMake/file/RunCMakeTest.cmake
index 3f3c0da..63cbdd9 100644
--- a/Tests/RunCMake/file/RunCMakeTest.cmake
+++ b/Tests/RunCMake/file/RunCMakeTest.cmake
@@ -36,4 +36,5 @@ run_cmake(GLOB-noexp-LIST_DIRECTORIES)
 
 if(NOT WIN32 OR CYGWIN)
   run_cmake(GLOB_RECURSE-cyclic-recursion)
+  run_cmake(INSTALL-SYMLINK)
 endif()

---

Summary of changes:
 Help/manual/cmake.1.rst|3 +++
 Source/cmFileCommand.cxx   |3 +++
 Tests/RunCMake/file/INSTALL-SYMLINK-stdout.txt |3 +++
 Tests/RunCMake/file/INSTALL-SYMLINK.cmake  |   13 +
 Tests/RunCMake/file/RunCMakeTest.cmake |1 +
 5 files changed, 23 insertions(+)
 create mode 100644 Tests/RunCMake/file/INSTALL-SYMLINK-stdout.txt
 create mode 100644 Tests/RunCMake/file/INSTALL-SYMLINK.cmake


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