_VERSION_MINOR 6)
-set(CMake_VERSION_PATCH 20160608)
+set(CMake_VERSION_PATCH 20160609)
#set(CMake_VERSION_RC 1)
---
Summary of changes:
Source/CMakeVersion.cmake |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
hooks/
Hi,
Since cmake can generate MSBuild build file, why could cmake support
building with Windows SDK? I searched the internet, and only found a few
posts talking about this, and there's a repo on Github which named
FindWindowsSDK.
Do we have any inside news from the core developers?
Thanks,
On 08/06/2016 12:11 p.m., Gonzalo Garramuño wrote:
I have a multiplatform viewer and recently I started to experience
some very weird behavior.
Found the problem being the volume control not being 32bits. Sorry for
the noise.
--
Powered by www.kitware.com
Please keep messages on-topic and
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 7c99e0fa021fcade3968d3ab75fb0bff5b04d809 (commit)
via
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 bcce79e9b7de4ae5fba7e7a1139586ccdf5c77e3 (commit)
via
I tried v3.6.0 rc1 but it fails on linking with a message about unknown
symbols when doing cmake -E vs_link_dll on a windows library. It seems
not to recognize the symbols in, for example, tinyxml2.
The same code works just fine under cmake v3.5.2.
--
Powered by www.kitware.com
Please keep
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 03a75bf379f0af616975da7421ea95ee669ee8b9 (commit)
via
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 7e7dd8ba118242cb86a944d130b91f7464028499 (commit)
via
> This could probably be supported by adding USE_SOURCE_PERMISSIONS for
> install(FILES ...) would you be willing to contribute a patch?
Misses that this is not cmake-dev mailing list... Patch would still be
appreciated but you could also file a feature request (for extending
the documentation
Hi folks,
I am wondering if it is possible to detect in CMakeLists.txt whether a Nightly
target is being configured?
What I am trying to do, is to set extra parameters (--gtest_repeat=200) on some
tests; but because this slows things down, I'd like to have this only in the
Nightly run.
Any
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 19eb5feb9d2e7e3b33b3402b1e5fb0c80560e647 (commit)
via
> Before running this cmake script, I am setting executable permissions on the
> build machine, where the package is created.
With install(FILES ...) command permissions set to source file will be
ignored by default (this is missing from documentation).
You could set permissions with PERMISSIONS
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 6455c5c0afeba7e9f7f5ecc8f04b25f1462157f8 (commit)
via
On 08/06/16 17:58, Kristian wrote:
> Hey guys,
>
> I am creating a RPM package with CMake. Here is a small example of how
> it looks:
>
>
>
> cmake_minimum_required(VERSION 3.5)
>
> set(BOOST_LIB "${CMAKE_CURRENT_SOURCE_DIR}/boost")
>
> file(GLOB_RECURSE BOOST_LIBRARIES ${BOOST_LIB}/*)
>
On 6/8/2016 12:59 PM, Bartlett, Roscoe A wrote:
Xavier,
Thanks for the info. I got another email from Brad King and he also
pointed out the same thing:
https://cmake.org/cmake/help/v3.6/command/ctest_start.html#command:ctest_start
and then Brad updated the documentation for
Xavier,
Thanks for the info. I got another email from Brad King and he also pointed
out the same thing:
https://cmake.org/cmake/help/v3.6/command/ctest_start.html#command:ctest_start
and then Brad updated the documentation for ctest_update() to state that it
will just keep you on
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 6c7dd8eb8ae00a1a0b8c628e4d6e3c7b5f3ea1f9 (commit)
via
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 ba92e11f8b461513566d5cc3c0b53b2215bb85f7 (commit)
via
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 5780391f96f58561e08ed115d1fd8a0c4e9695d8 (commit)
via
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 5a13dc0b6e462745e12946e209b815131ea47f25 (commit)
via
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 fb8b8dd1060f78729da7b79c7eea06601681b678 (commit)
via
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 5804068c220e2f9870dbcb24ee68eb610c9b4ff4 (commit)
via
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 c3ba3a40a15ed8187d26dcfebf797b54158f96e3 (commit)
via
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 5572f5fffd040473c588215a7c87a12530e1548e (commit)
via
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 8632251b25c217e12ae8741e935d6b9aa03ac04b (commit)
via
Hi,
the code looks right to me. Thanks a lot for fixing that so quickly.
Brad is also right about the first byte. The command has the argument
already attached.
Michael
On 06/08/2016 06:46 PM, Brad King wrote:
> On 06/08/2016 12:43 PM, Rolf Eike Beer wrote:
>>> Run ranlib on archives only if
On 06/08/2016 12:43 PM, Rolf Eike Beer wrote:
>> Run ranlib on archives only if the tool is available
>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea598671
>
> Shouldn't the first check also be "cmd == ":" instead of only
> checking the first byte?
No, because the command in question
Hi Ross,
Here is how I do it in my case:
...
# Initial checkout if no source directory
if(NOT EXISTS "${CTEST_SOURCE_DIRECTORY}")
message("Initial checkout...")
set(CTEST_CHECKOUT_COMMAND "git clone --branch ${GIT_BRANCH}
${REPOSITORY} ${SOURCE_DIR_NAME}")
endif()
# Initialize testing
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 0b5f5857d3cbf5ce77c78fcaef36c4cd001cd4f0 (commit)
via
Am Mittwoch, 8. Juni 2016, 12:24:29 schrieb Brad King:
> On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote:
> > the : is obviously the default for noop which is correct for
> > Linux but not for Windows. My CMakeCache has the following entry:
> > //noop for ranlib
>
> > CMAKE_RANLIB:INTERNAL=:
> I
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 7160c8c8dea75dda8f016823ed0a0ff2e922fdef (commit)
via
On 06/08/2016 03:33 AM, "Michael Jäntsch" wrote:
> the : is obviously the default for noop which is correct for
> Linux but not for Windows. My CMakeCache has the following entry:
> //noop for ranlib
> CMAKE_RANLIB:INTERNAL=:
I see that here:
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 9a4fa800379b26bfbae3a9a98ed94baf58166713 (commit)
via
If the projects are each providing their own Config.cmake file then you
probably will want to use those instead of Find modules. Instead of using
the Foo_Bar_LIBRARIES variable though, try using the actual imported
targets from the config files. Those should have the appropriate
dependency
Hey guys,
I am creating a RPM package with CMake. Here is a small example of how it
looks:
cmake_minimum_required(VERSION 3.5)
set(BOOST_LIB "${CMAKE_CURRENT_SOURCE_DIR}/boost")
file(GLOB_RECURSE BOOST_LIBRARIES ${BOOST_LIB}/*)
install(FILES
In my case all projects provide their own FooBarConfig.cmake, but not a
FindFooBar.cmake. For this reason I wanted to use those, because I
thought it saves me the effort of writing a lot of FindFooBar.cmake
files, and it also seemed like the right way to do it, because it
provides things like
I have a multiplatform viewer and recently I started to experience some
very weird behavior.
I am using the latest cmake 3.5.3 rc1 and the latest released ninja
(1.7), albeit the problem appears with NMake Makefiles too.
The viewer links against winmm.dll, the windows multimedia library for
I was able to verify, btw, that Fedora 19 + Power8 outputs ppc64le for
uname -m so I assume it works correctly on EL7 as well. Testead via an IBM
machine hosted at the OSU Open Source Lab that we can access and use for
testing.
- Chuck
On Wed, Jun 8, 2016 at 10:33 AM, M Kelly
Domen Vrankar writes:
>
> > The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake
> > --system-information) uses the same "uname -m"
> > see Modules/CMakeDetermineSystem.cmake.
> >
> > So there is something odd to have one right and the other wrong...
>
>
Hi Tobias,
So it looks like I was completely wrong in pointing you at GetTargetFlags
to get compiler flags. It is indeed for linker flags.
On 06/08/2016 04:23 AM, Tobias Hunger wrote:
> what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It
> is
> only ever set for
On 06/07/2016 05:54 PM, Roger Leigh wrote:
> I've merged this bzip2-debug-names branch into next for testing.
Looks good, 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
On 06/08/2016 01:24 AM, Tobias Hunger wrote:
>> cmLocalGenerator: Pass configuration to GetTargetFlags
>> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fe0d2241
>
> Great, thanks!
I had to revert it from 'next' because it caused several LinkFlags
test failures. The reason is that it
On 06/08/2016 04:05 AM, Stephen Kelly wrote:
> I have rebased it and force pushed my github branch (there are a few
> rebasing mistakes which I'll remove later).
Thanks.
> We hit issues at work that different clang-format versions have
> different behavior. There we have the luxury of providing
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 15e1ee72d6d13ab02cbfd727a5702a7ce8bd18a2 (commit)
via
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 fcd706a47df8800fb7ad6cfac783ea40f184f4e5 (commit)
via
The FooBarConfig.cmake is something that should be generated by FooBar's
build. The reason you don't get absolute paths for the "libraries" from a
package config file is that they're not actually libraries but imported
targets. The imported target let's you treat "foo" as though it were a
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 cdc2c6a7a48b66f043a832d0417a1475b53cb63f (commit)
via
Thanks you for the fix and tips!
Brad
From: Brad King [brad.k...@kitware.com]
Sent: Tuesday, June 07, 2016 3:13 PM
To: Lowekamp, Bradley (NIH/NLM/LHC) [C]
Cc: CMake@cmake.org
Subject: Re: [CMake] Problem building CMake with system OPENSSL
On 06/07/2016
Hi everybody,
what use is the "flags" out-parameter in cmLocalGenerator::GetTargetFlags? It is
only ever set for targets of type EXECUTABLE and is filled based on the *linker
language* of the target.
I really do not see any use for this information, and indeed the flag seems
unused in the cmake
Hi,
In cmake 3.5.0, 3.5.2 and 3.6.0, my resource file is compiled every time
I build, even when they are not changed.
|
cmake_minimum_required(VERSION 3.2)|
|project(auto_moc_uic_rcc)set(CMAKE_INCLUDE_CURRENT_DIR
ON)set(CMAKE_AUTOMOC ON)set(CMAKE_AUTOUIC ON)set(CMAKE_AUTORCC
ON)find_package
> The strange thing is that CMAKE_HOST_SYSTEM_PROCESSOR (outputed by cmake
> --system-information) uses the same "uname -m"
> see Modules/CMakeDetermineSystem.cmake.
>
> So there is something odd to have one right and the other wrong...
In that case it's quite possible that
2016-06-08 9:45 GMT+02:00 Domen Vrankar :
> > I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6
> > (default cmake from repo was 2.8.12?) but it seems when making a package
> > the arch is set incorrectly to x86_64 instead of ppc64le.
>
> I don't
On 06/07/2016 11:42 AM, Daniel Pfeifer wrote:
> On Mon, Jun 6, 2016 at 7:24 PM, Brad King wrote:
>> On 06/06/2016 11:39 AM, Tobias Hunger wrote:
>>
>>> A big chunk of Stephen's work has not even landed in my branch yet. Since
>>> cmake
>>> reformated all the source in the
> I am working on an IBM Power8 RHEL7.2 system and we installed cmake 3.6
> (default cmake from repo was 2.8.12?) but it seems when making a package
> the arch is set incorrectly to x86_64 instead of ppc64le.
I don't have access to a ppc with Linux but it seems that 'uname -m'
(default that is
Ah ok. That is interesting. If I set the CMAKE_RANLIB (after my Project command) it gets executed correctly. Interesting is that this is not needed for mingw makefiles. I also do not know how to set the RANLIB properly in my toolchain file.
Either way, the : is obviously the default for noop
55 matches
Mail list logo