We have a cmake based project where cmake runtime is becoming a problem:
everytime a CMakeLists.txt changes the build takes an extra 40-50 seconds. Our
main CMakeLists.txt contains a lot of ADD_SUBDIRECTORY (and little else).
Most of the subdirectories then call FIND_PACKAGE(Qt4) with
On a practical matter though: if the file is not listed someplace, then your
IDE may not pick it up. Thus while it is legal to not list all files, it is a
good idea to list them anyway.
-Original Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Our normal coding standards requires zero warnings with -wall -wextra
(gcc/clang), but often the swig generated file has warnings. We don't mind
turning these warnings off for the generated file, but we still want to see
them for other files in the project. However I'm stumped on how to do
Our build it taking a long time, (15+ minutes even when with a massive build
farm to distribute compiles across), and the question keeps coming up: what is
actually taking so long. Is there an easy way to measure?
If there are some top 10 files we might be able to split them (reducing some
Nice theory, but I have to deal with the real world where many projects don't
provide a project config .cmake script. They see no reason to: they don't build
with cmake, other downstreams don't build with cmake. It seems to them that
they are supporting one system, and there are hundreds. I do
We are using cmake 2.8.11 for out project.
Our local compiler is gcc-4.4.3. There is desire to use a newer compiler, but
we are not yet ready to commit to anything yet. In the mean time we have
installed binaries gcc-4.7 and gcc-4.8. We can specify the alternate compiler
with
-
From: Игорь Пашев [mailto:pashev.i...@gmail.com]
Sent: Wednesday, September 11, 2013 11:31 PM
To: Miller Henry
Cc: cmake@cmake.org
Subject: Re: [CMake] Alternate compiler specific options - how to specify?
2013/9/11 Miller Henry millerhe...@johndeere.com:
We are using cmake 2.8.11 for out
I just switched to using ctest, which is overall much better, but when I run
with -j it often happens that some test suite fails. After investigating I
discovered that the failing test is not a unit tests (ie a test with everything
mocked out), but an integration test that is intentionally
I'll second (third) the vote for uncrustify over astyle. Astyle doesn't have
enough options to take care of all style issues, with uncrustify you can
configure everything. Also check out clang-format - it only supports 3 styles
(last I checked), but if one of them fit it might be easiest.
One of my co-workers just did a build where they ran cmake with the option
-DCMAKE_BUILD_TYPE=RelWithDebugInfo Of course what was obviously meant was
RelWithDbgInfo. Because of this incorrect option the build was not as
expected, but it took a while to figure out why it failed. Of course
You need to use include_directories to tell cmake where to find headers.
include_directories(${CMAKE_SOURCE_DIR}/src)
http://www.cmake.org/cmake/help/v3.0/command/include_directories.html
http://www.cmake.org/cmake/help/v3.0/variable/CMAKE_SOURCE_DIR.html
From: CMake
I develop a shared library that gets imported into a number of applications
(scattered across a number of different repositories). To aid in testing we
provide some mocks and fakes, made available by a cmake export files.
This works okay, but it isn't right: google mock doesn't guarantee
I'm trying out my project on 3.3.0-rc1, but currently I'm using 2.8.11 and
2.8.12. I got a couple errors from CMP0046. Most of them are correct: I've
fixed a couple places where a non-existent dependency was used, and I want to
set this policy to NEW so that more do not sneak in.
However
Use find_library to find the library. You will probably need this anyway
because different systems install libraries in different locations.
http://www.cmake.org/cmake/help/v3.3/command/find_library.html
From: CMake [mailto:cmake-boun...@cmake.org] On Behalf Of Ette, Anthony (CDS)
Sent:
I do something like this, which works for clang and should work for gcc 4.9
though I haven't tested it. I haven't wrote the right way to do this which is
to check if the terminal supports color before passing the flag in. I don't
know what will happen on our e.g. CI system which doesn't
I'm using cmake to build a set of libraries that then gets packaged and shipped
to other groups that are also using cmake to use the library. Since I use
google mock to mock my libraries, and the downstreams also want to mock my
library I just provide the mock header for their use. This
I found the same thing a few years ago, and my solution was the same: only
include those modules once. I find that my sub cmake modules are much cleaner
now as a bonus.
I tend to blame the time not on file IO, but on time to parse those files.
I've never done actual profiling though.
I hate to state the obvious, but
set_property (TEST test2 PROPERTY LABELS LABEL1 LABEL2 LABEL1andLABEL2)
I know it isn’t what you asked for, but I don’t want cmake to change, but I
don’t think it is worthwhile to add more complex set algebra to the -L command
so that we can support complex
I have a few different cmake based projects that depend on each other (as a
tree, no circular dependencies). Mostly this works great, but a few people
have expressed interested in a superbuild which builds everything together for
various purposes. I can make this work with ExternalProject,
A superbuild will work, and you can write your own Find*.cmake so that
find_package works - you don't need most of what the real Find_package would do
for you because you already know what is installed where as you control that.
But, can you live with the trade off: long build times?
What my
I'm going to ask two questions, but a good answer to the first will make the
second question redundant.
I work with several different cmake projects that are cross compiled, and they
depend on each other. Each project creates a cmake config, so we can use
find_package to find the contents.
I have found the following projects which all seem to do some variation of a
meta build so that you can build multiple projects that depend on each other
and manage dependencies. (there are a couple others that seem to not be
maintained as well)
https://gradle.org/
https://bazel.build/
Instead of trying to do this with the toolchain somehow in cmake I think you
might want to look into a meta build system that handles the toolchain and all
other dependencies. I listed all I know of a couple months ago in this thread.
https://cmake.org/pipermail/cmake/2017-March/065229.html
in official cmake documentation, but it
seems like something that has never been done before.
-Original Message-
From: Robert Maynard [mailto:robert.mayn...@kitware.com]
Sent: Tuesday, August 22, 2017 9:46 AM
To: Miller Henry <millerhe...@johndeere.com>
Cc: cmake@cmake.org
Subject: Re:
I've been playing with the private/public/interface keyword to
target_link_libraries. It seems to me that WHAT they do is well documented, but
nobody has ever actually documented what they correct rules of WHEN/WHY you
should use any of them. After a lot of misstarts I think I've started to
I have a fairly large project that I'm trying to update from building with
cmake 2.8.12 to 3.10.2. When I make the change my build times go up by half on
our Jenkins ci build system. The build machines are 32 core and my build time
goes from 59m 38s to 1h 28m 33s. When I try this locally the
There are two options. Each with pros and cons.
The first what you are doing now, except you use external project
https://cmake.org/cmake/help/v3.12/module/ExternalProject.html to build the
host tools instead of add_custom_command. It otherwise has all the cons you
mention, but are they
I like the idea, some tweaks that I think you need
add_host_build - executables built here need to be available not as targets,
but as variables as if FIND_EXECUTABLE was called on them. This is probably
what you meant, but it didn't come across that way.
In the case where you are cross
We have had luck packaging all the CTestTestFile.cmake files, and using sed to
adjust paths for the target location. You need to install ctest on the test
machine, along with all the tests.
The only paths we change are the test output location (ie google test .xml
files: this might not apply
Easy enough. ADD_TEST can run whatever you want.
I created a simple cmake function
Function(RUN_REMOTE_TEST testname, other_args)
# insert useful code here…
add_test(${testname}
remote_run_test ${binary_dir}/${testname} other test runner script args…
)
End_function()
You will have
30 matches
Mail list logo
