Thanks for this Brad, your comments in
https://cmake.org/Bug/view.php?id=15929#c40287 make it very clear as to
what is happening.
I had naively assumed that when installing a new Visual Studio compiler
that the latest SDK would be also installed! It is nice to see that CMake
3.4.2 does the checks
On 1/21/16, David Morsberger wrote:
> Eric,
>
> I went down a rabbit hole and pulled myself back out. I narrowed it down to
> the following.
>
> We are using cmake to check if the linker supports -Wl,—as-needed. The test
> compile (and link?) command cmake builds using ‘cmake -G Xcode’ does not
>
On 1/21/2016 2:33 PM, Kügler, David wrote:
Hello everybody,
I am trying to build a Project (via ExternalProject from a parent project).
More precisely, I want to build the plus Toolkit (plustoolkit.org) and
the subprojects using the build “superproject” (i.e. PlusBuild).
It partly seems to wor
El 21/01/16 a las 15:47, Brad King escribió:
Thanks. From that I was able to reproduce it in a small test case
with CMake 3.4. It appears that the problem has been fixed since
then in 'master'. I've added a test case to keep it working:
I confirm the bug is squashed in master! Congratulation
Hello everybody,
I am trying to build a Project (via ExternalProject from a parent project).
More precisely, I want to build the plus Toolkit (plustoolkit.org) and the
subprojects using the build "superproject" (i.e. PlusBuild).
It partly seems to work fine, but the ExternalProject PlusApp neve
On 21/01/2016 03:47 p.m., Brad King wrote:
On 01/21/2016 11:00 AM, Gonzalo wrote:
Find attached the mrViewer/src/CMakeList.txt file that still fails.
Thanks. From that I was able to reproduce it in a small test case
with CMake 3.4. It appears that the problem has been fixed since
then in 'mas
On 01/21/2016 11:00 AM, Gonzalo wrote:
> Find attached the mrViewer/src/CMakeList.txt file that still fails.
Thanks. From that I was able to reproduce it in a small test case
with CMake 3.4. It appears that the problem has been fixed since
then in 'master'. I've added a test case to keep it wor
Hi Cedric,
I believe you should do it this way:
Your config.cmake file should be:
set(ENABLE_DOWNLOAD True CACHE BOOL "")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "")
In the signature of set() for "Set Cache Entry", the *docstring* is
mandatory.
cf https://cmake.org/cmake/help/v3.4
El 21/01/16 a las 10:28, Brad King escribió:
Thanks. This is consistent with the call stack shown in your original
post. That line is always executed so we need to figure out what goes
wrong with it in your particular case. Since you can reproduce it in
I forgot to mention. FLTK2.0 is avail
Thanks. This is consistent with the call stack shown in your original
post. That line is always executed so we need to figure out what goes
wrong with it in your particular case. Since you can reproduce it in
mrViewer's configuration that is a good starting point. Try removing
sources and li
Thank you Chuck & Petr!
It works fine now! :)
Cédric
- Chuck Atkins a écrit :
>CMake strongly encourages the use of separate source and build directories
>(unlike autotools). So, try something like this:
mkdir build
cd build
cmake -C /path/to/SuperCoolCacheFile.cmake /path/to/source
-
CMake strongly encourages the use of separate source and build directories
(unlike autotools). So, try something like this:
mkdir build
cd build
cmake -C /path/to/SuperCoolCacheFile.cmake /path/to/source
- Chuck
On Thu, Jan 21, 2016 at 10:10 AM, Cedric Doucet
wrote:
>
>
> Hi Petr,
>
> thank
It looks as if CMake was interpreting the path as both the source directory
and the initial cache file. Perhaps you could help it by adding the path to
source explicitly:
cmake -C ../config.cmake whatever/your/path/to/source/is
Petr
On Thu, Jan 21, 2016 at 4:10 PM, Cedric Doucet
wrote:
>
>
> H
Hi Domen,
Thanks a lot for the tip! I'll give it a try. (The "monolithic limitation"
should not be an issue for us. We do build single RPMs for our projects.)
Cheers,
Attila
> On 21 Jan 2016, at 00:49, Domen Vrankar wrote:
>
>> I have a slightly unusual question (I guess). Is it p
Hi Petr,
thank you very much for your answer!
Indeed, comment string arguments seem to be mandatory.
I modified my configuration file like this:
set(ENABLE_DOWNLOAD True CACHE BOOL "Automatic installation of third-party
libraries")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Root of
Nice, thank you very much! This solves my problem.
On Thu, Jan 21, 2016 at 3:56 PM, Nicholas Braden wrote:
> Ah, I ran into this quirk too - the issue is that you have the quotes
> incorrect:
>
> -DCMAKE_CXX_FLAGS="-march=native"
>
> Should be like this instead:
>
> "-DCMAKE_CXX_FLAGS=-march=nat
Hi Cedric,
The option can be a bit confusing. The cache file you pass is actually a
CMake script that sets cache variables, rather than the cache variables as
seen in CMakeCache.txt. So you would actually want your cache file to
contain:
set(CMAKE_BUILD_TYPE Debug CACHE STRING "Choose the type
Hi Cedric.
I believe the comment string argument is mandatory in a set(... CACHE), so
it should be something like this:
set(ENABLE_DOWNLOAD True CACHE BOOL "Should download be enabled")
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH "Path to root directory
of GCC installation")
Petr
On Th
Ah, I ran into this quirk too - the issue is that you have the quotes incorrect:
-DCMAKE_CXX_FLAGS="-march=native"
Should be like this instead:
"-DCMAKE_CXX_FLAGS=-march=native"
Try that and see if it helps, I am pretty sure I ran into the exact
same problem.
On Thu, Jan 21, 2016 at 8:27 AM, f
On Thu, Jan 21, 2016 at 3:26 PM, Vania Joloboff
wrote:
> HI Petr
>
> Thanks for the suggestion.
> But this will erase the existing compile definitions, won't it ?
> So may be I should do a get_property first,
> append my new definitions and reset the property ?
> I'll try anyway...
>
This would
2016-01-21 15:14 GMT+01:00 Vania Joloboff :
> Hi
>
> I want to add two definitions to compile one specific files
> in addition to the global definitions.
> I have the following problem. If I use
>
> set_source_files_properties(source.cpp
> PROPERTIES
> COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY
Hello,
I do not manage to pass a configuration file to cmake.
I type 'cmake -C ../config.cmake'
where config.cmake belongs to the parent directory and contains these lines:
set(ENABLE_DOWNLOAD True CACHE BOOL)
set(GCC_ROOT "/local/cdoucet/gcc/4.9.2/" CACHE PATH)
I get the following error mess
Use APPEND keyword:
set_property(
SOURCE source.cpp
APPEND PROPERTY COMPILE_DEFINITIONS
VAR1=${MY_VAR1} VAR2=${MY_VAR2}
)
On 21/01/16 15:26, "CMake on behalf of Vania Joloboff" wrote:
>HI Petr
>
>Thanks for the suggestion.
>But this will erase the existing compile definitions, won't
Thanks for your suggestion! I consider trying it soon.
On Wed, Jan 20, 2016 at 11:44 PM, Craig Scott
wrote:
>
> From: fkillus
>> To: cmake@cmake.org
>> Cc:
>> Date: Wed, 20 Jan 2016 18:41:26 +0100
>> Subject: [CMake] ExternalProject_Add() macro does not set
>> CMAKE_COMPILER_IS_GNUCXX
>> I have
Thanks for clarifying that external projects are not aware of the project
they are embedded in.
The CMAKE_COMPILER_IS_GNUCXX variable should be set automatically by CMake
as far
as I understand it (see https://cmake.org/Wiki/CMake_Useful_Variables).
I narrowed down the problem by creating a minima
HI Petr
Thanks for the suggestion.
But this will erase the existing compile definitions, won't it ?
So may be I should do a get_property first,
append my new definitions and reset the property ?
I'll try anyway...
Vania
On 01/21/2016 03:21 PM, Petr Kmoch wrote:
Hi Vania.
For your case, it's b
Hi,
On 21/01/16 15:14, Vania Joloboff wrote:
Hi
I want to add two definitions to compile one specific files
in addition to the global definitions.
I have the following problem. If I use
set_source_files_properties(source.cpp
PROPERTIES
COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
the
Hi Vania.
For your case, it's best to forget about the
not-as-convenient-as-they-could-be convenience functions set_*_properties,
and just invoke set_property:
set_property(
SOURCE source.cpp
PROPERTY COMPILE_DEFINITIONS
VAR1=${MY_VAR1} VAR2=${MY_VAR2}
)
Petr
On Thu, Jan 21, 2016 at 3:1
Hi
I want to add two definitions to compile one specific files
in addition to the global definitions.
I have the following problem. If I use
set_source_files_properties(source.cpp
PROPERTIES
COMPILE_DEFINITIONS VAR1=${MY_VAR1} VAR2=${MY_VAR2} )
then I get error message incorrect number of argum
Eric,
I went down a rabbit hole and pulled myself back out. I narrowed it down to the
following.
We are using cmake to check if the linker supports -Wl,—as-needed. The test
compile (and link?) command cmake builds using ‘cmake -G Xcode’ does not fail.
The command from ‘cmake -G’ has been narr
On 01/20/2016 04:36 PM, Andrew Maclean wrote:
> "CMake Error at CMakeLists.txt:1 (project):
> Could not find an appropriate version of the Windows 10 SDK installed on
> this machine"
>
> In CMakeOutput.log, there is one line:
> "The system is: Windows - 10.0.10586 - AMD64"
It looks like thi
On 01/21/2016 07:53 AM, Gonzalo wrote:
> I delved into the cmake 3.4.2 source code and found the offending line
> in cmTarget.cxx:
>
> cmSystemTools::ExpandListArgument((*it)->ge->Evaluate(mf,
>config,
>
El 20/01/16 a las 15:51, Brad King escribió:
It's not gone or even deprecated. It's just not well tested
and seems to be broken in your particular case in a way not
reproduced by the test.
I delved into the cmake 3.4.2 source code and found the offending line
in cmTarget.cxx:
cmSystemTo
I would also be very much interested how this could be done. There was a thread
I started a few months ago on a similar topic. I wanted to see the execution
times of various tests without the initialization part. If my tests could
output in some form the useful part of their run times, it would
34 matches
Mail list logo
