You can use the COMPONENT option to install() for your own project and then
select a component-based package if you are packaging with CPack. We
currently do this with builds that incorporate other projects with
add_subdirectory() similar to your case.
If you are using install as a build target (i
Hello all!10:00, 16 February 2017 г., Milan Ziegler :Hi,we are using the CMake install mechanism "install(...)" to copy allrelevant files and target binaries of the product into the CMake installprefix folder, for further packaging. So far so good.We are also using several thirdparty libraries, hos
Hi,
we are using the CMake install mechanism "install(...)" to copy all
relevant files and target binaries of the product into the CMake install
prefix folder, for further packaging. So far so good.
We are also using several thirdparty libraries, hosting them inside our
own repository and buildin
When I run
php5 autoRemoveBuilds.php all
for my cdash 2.2.3 installation, I see the following errors (and old builds are
not removed):
removing builds for all
-- removing old buildids for projectid: 2
PHP Warning: mysql_fetch_array() expects parameter 1 to be resource, boolean g8
PHP Warning
Hi Adrian,
So, would this imply that cmake is not supported on EL7 because gcc does
> not support cxx11 ?
>
That's not really what's happening. CMake is testing the C compiler to
determine whether or not it supports C11 features and the C++ compiler to
see if it supports C++11. The error messag
15.02.2017, 20:08, "Bill Newcomb" :
> My top-level CMakeLists.txt files always end up with a lot of
>
> if(NOT_DEFINED foo)
> set(foo bar)
> endif()
>
> things to allow people to pass interesting things on the command line or
> to write their own "set this and that" CMakeLists.txt and includ
I found that changing the add_definitions lines to
set(CMAKE_C_FLAGS_INIT ...) or set(CMAKE_CXX_FLAGS_INIT ...)
resolved the issue. I have not found documentation anywhere that
says "this is how it must be done".
So, is this the expected behavior when using add_defin
My top-level CMakeLists.txt files always end up with a lot of
if(NOT_DEFINED foo)
set(foo bar)
endif()
things to allow people to pass interesting things on the command line or
to write their own "set this and that" CMakeLists.txt and include the
top-level one.
It would improve readability
Toolchain is probably what you want
http://stackoverflow.com/questions/9129233/recommended-ways-to-use-cmake-with-icc-via-configuration-options
https://cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F
"cmake intel toochain" search.
On Wed, Feb 15, 2017 at 6:42 AM, Thompson, KT
You can either unpack the target at generation time (recommended).
Or you could create an INTERFACE target instead.
The first solution is recommended as I believe it's important to have
access to all the sources (for IDEs for example) before actually
starting the build process.
/Florent
On 1
Tony,
I don’t have access to the Intel compiler on Windows to try this out. However,
in an old post I found, it was suggested that you can use cmake’s “-T” option
to select the Intel compiler when the generator is “Visual Studio”.
For example: -T"Intel C++ Compiler XE 13.0"
Ref: https://softw
On 15.02.2017 15:16, Malfettone, Kris wrote:
Just noticed a problem in my example. In my attempt to simplify my
example I moved both outputs into the same folder which in my opinion
is invalid because both output file names are the same. However, the
same basic setup does reproduce the prob
Just noticed a problem in my example. In my attempt to simplify my example I
moved both outputs into the same folder which in my opinion is invalid because
both output file names are the same. However, the same basic setup does
reproduce the problem if you move the two targets into their own s
So I was able to reproduce the problem with this very simple CMakeLists.txt
setup. I cannot attach source files due to my company's mail server
automatically stripping them out attachments with code but here is all you
would need to reproduce the problem:
Single CMakeLists.txt with the followi
Good to know. Thanks for the quick response. Though I do not believe I am
violating that particular rule here. That is why I do not receive either a
warning or error from CMake in my output.
The only warning I see is from ninja:
ninja: warning: multiple rules generate MD/MDF/Formats/SIG/BCP/v
Re: my previous email. To use the Intel C compilers I just can modify the
VS settings. So I have a way forward.
Regards,
Tony
On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch wrote:
> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> generator for Visual Studi
Hi @all,
I’ve tried importing an external library like that:
stackoverflow.com/questions/31274577
I have the same use case, except that my custom target does not call make but
does unpack a tar archive containing headers and .a.
My problem is that the step
“
# specify where the library is and w
I tried setting the FC and CC variables and yet cmake still wants to use
the Microsoft compiler (BTW what I am building is the CGNS - the CFD common
file format).
Is there something I am missing?
CGNS_Build>set CC=icc
CGNS_Build>set FC=ifort
CGNS_Build>set CC
CC=icc
CGNS_Build>set FC
FC=ifort
Thank you so much Petr. I am new to cmake so did quite understand how
everything fits together. I will give your suggestion a try.
Regards,
Tony
On Wed, Feb 15, 2017 at 12:25 PM, Petr Kmoch wrote:
> Hi Tony,
>
> generators are for different *buildsystems*: a generator for Makefiles, a
> gen
Hi Tony,
generators are for different *buildsystems*: a generator for Makefiles, a
generator for Visual Studio solutions, a generator for Ninja files, a
generator for Eclipse projects etc.
Intel C and Intel Fortran are compilers, not buildsystems. You should be
able to use them with any generator
I am having to switch to cmake from autotools for a third party tool I want
to build. We use Intel C and Intel Fortran on Windows. I see no mention of
an Intel C generator for cmake. I presume this means there is not one? If
so, can I create my own Intel C generator please?
Rgeards,
Tony
--
*Dr
On 14.02.2017 22:53, Malfettone, Kris wrote:
If so, are executables named “test” no longer supported?
Am I missing something or wrong in some way?
Issues existed before 3.0 but since 3.0 "test" and similarly problematic
target names have been explicitly reserved.
Any CMake Version >= 3.0 w
22 matches
Mail list logo
