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,
David
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
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 m
> 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 reg
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 an
> 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 a
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 ctest_updat
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 whateve
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
mess
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 inform
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 ${CMAKE_CURRENT_SOURCE_DIR}/usr/bin/execut
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 FooBa
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
audi
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 wrote:
> Domen Vr
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...
>
> In that case it's qu
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
librar
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 10:
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 CPACK_RPM_PACKAGE_ARCHI
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 have access to a ppc with Lin
> 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 use
22 matches
Mail list logo
