A round of performance improvements to generate time was done as part
of CMake 3.11 and that significantly helped. What would be helpful is
a performance analysis run of CMake itself to determine if the issue
is that we are IO bound ( and need to do multi-threaded writes ) or
compute bound.
While
Hi,
CMake has for Visual Studio is a multi configuration generator. (Debug,
Release, RelMinSize, RelWithDbgInformation).
If you specify only one configuration you should cut the generation time to
1/4th.
See
https://cmake.org/cmake/help/latest/variable/CMAKE_CONFIGURATION_TYPES.html#variable:CMA
Hello,
On 17.11.16 17:15, Damian wrote:
We are still in the process of switching our large Make-based build to
CMake. One of the issues we're running into is the time it takes to
reparse and regenerate the CMake project (whether ninja, VS, or make)
after touching any CMake file. To give you an
The best advice I had for myself: profile the code and tweak it. The last I
looked, and that was a while ago, the generators could use a threaded write
queue so that the file output would overlap with file generation. Those
probably could be memory mapped files, too, to further minimize the over
On Wed, 2019-03-20 at 16:57 -0400, J. Caleb Wherry wrote:
> I was also surprised when "cmake --trace" gave 0 information related
> to the generate step. I assume this is expected behavior?
The purpose of --trace is to debug CMake scripts. No scripts get run
during the generate step, so yes, this is
I was also surprised when "cmake --trace" gave 0 information related to the
generate step. I assume this is expected behavior?
Oh and:
CMake: 3.13.4
Visual Studio 2017 15.9.9
Win7
-Caleb
On Wed, Mar 20, 2019 at 4:53 PM J. Caleb Wherry
wrote:
> Did anything ever come of this?
>
> I am in a sim
Did anything ever come of this?
I am in a similar boat: we have >800 targets on our full build (native C++,
Managed C++, C#, Java, CUDA, etc) and the majority of the time for the
configure/generate steps takes place in the generate step (>70%).
I understand there is a lot of IO since the generate
Hi,
I'm trying to use fpp preprocessor in a Fortran project built with CMake. For
example,
I have two source files. The file x.f90 defines module x:
module x
#ifdef ENABLE_Z
use z
#endif
implicit none
end module x
The module z used in module x is defined in z.f90 as followed:
module z
i
Hi all,
We are still in the process of switching our large Make-based build to
CMake. One of the issues we're running into is the time it takes to reparse
and regenerate the CMake project (whether ninja, VS, or make) after
touching any CMake file. To give you an idea, we have about 1000 targets
an
You can write the root cmake file in the samples directory then adding
project specific cmake file in the src directory.
You can also start by writing a single cmake file in the
src directory alone. Then move it to the samples directory, if the project
complexity increases
On Tue, Dec 16, 2014 at
I am a new bee in Cmake. I want to make a project with Cmake. The Project
lay out is given below.
deepak/
gales/
directory_1_of_header_files/
directory_2_of_header_files/
directory_3_of_header_files/
samples/
The terminology of in-source and out-of-source for where the
CMakeLists.txt and *.cmake files exist temporarily threw me off, as
with CMake, in-source and out-of-source usually refer to where the
generated build files are placed.
On Wed, Jun 4, 2014 at 12:23 AM, Adam wrote:
> Thanks for the comme
Thanks for the comments I've update the wiki. Top-level only now marked as
anti-pattern
https://github.com/toomuchatonce/cmake-examples/wiki/cmake-patterns-and-examples
If there are other patterns / anti-patterns you've seen please send me a
pull request and I'll add them.
I'm particularly intere
"Just put all the build commands in the top level cmake file."
Definitely an anti-pattern. As you mentioned, it definitely doesn't
scale. The problem with even doing this for a simple project is that it
builds this behavior for people trying to learn cmake through simple
examples. This very ver
Great to see these examples with pros and cons.
I believe the staticlibs-include example [0] pattern, though mentioned
in Mastering CMake [1], generally is deprecated in favor of
add_subdirectory with CMakeLists.txt at each level for self-contained
projects.
[0]
https://github.com/toomuchatonce/
There's a lot of legacy examples around the web but not too many using the
newer features. What is the current best practise?
Here's some simple examples
https://github.com/toomuchatonce/cmake-examples/wiki/cmake-patterns-and-examples
Are these patterns or anti-patterns?
Regards,
Adam
--
Powe
Hi,
I just switched from ExternalProject to add_subdirectory.
The reason for me to switch was
(just discussed a few days ago on this list)
that with ExternalProject there is no automatic way
to get nice IDE project files.
My "reason" to use ExternalProject was that I didn't understand
that I coul
Hi,
I'm working on getting our CMake project to build the other libraries we wrote
and I'm not sure how it needs to be done. Our main code is a git repository and
inside the repo is a lib/ directory with git submodules for our other
libraries.
What is the best way to get the main project to b
On 4. Mar, 2010, at 14:02 , Flo wrote:
> Hello,
>
> For our Project, we need a structure where its possible to work/test/deploy
> a single module and also build products which uses some modules.
>
> f.e
>
> MODULE 1
> /bin
> /scr
> /test-src
> CMakeLists.txt
>
> MODULE 2
>
Hello,
For our Project, we need a structure where its possible to work/test/deploy
a single module and also build products which uses some modules.
f.e
MODULE 1
/bin
/scr
/test-src
CMakeLists.txt
MODULE 2
/bin
/src
/test-src
CMakeLists.txt
PRODUCT 1
Martin Guillon wrote:
Wow I didn't know about CMAke inserting the project thingy!!!
Ok now let me explain a little more. We want to simplify our
Cmakelists and make macros to help our users.
Now thanks to you we figured out the source of the problem. This is
the CMakeLists we want
SET (CMAKE_
ginal Message-
From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of
Bill Hoffman
Sent: Wednesday, February 10, 2010 5:22 PM
To: Tyler Roscoe
Cc: cmake@cmake.org; Martin Guillon
Subject: Re: [CMake] [CMAKE] PROJECT command and CMAKE_SYSTEM_NAME
Tyler Roscoe wrote:
> On
Tyler Roscoe wrote:
On Wed, Feb 10, 2010 at 04:54:47PM +0100, Martin Guillon wrote:
Let s say we have a very simple CMakeLists.txt Like that
cmake_minimum_required(VERSION 2.6)
MESSAGE (STATUS "The system is \"${CMAKE_SYSTEM_NAME}\"")
Now as is the CMakelists works fine.
The problem appears w
On Wed, Feb 10, 2010 at 04:54:47PM +0100, Martin Guillon wrote:
> Let s say we have a very simple CMakeLists.txt Like that
>
> cmake_minimum_required(VERSION 2.6)
> MESSAGE (STATUS "The system is \"${CMAKE_SYSTEM_NAME}\"")
>
> Now as is the CMakelists works fine.
>
> The problem appears when we
Hi,
We just found out something really weird about the command PROJECT.
Let s say we have a very simple CMakeLists.txt Like that
cmake_minimum_required(VERSION 2.6)
MESSAGE (STATUS "The system is \"${CMAKE_SYSTEM_NAME}\"")
Now as is the CMakelists works fine.
The problem appears when we add a
Is there anyway to create a project that contains only the
CMakeLists.txt file without any sources/headers? We have an external
Plugins directory within our repository which we do not want to combine
with the core programs sources.
Directory Structure
Plugins_dir -> plugin 1 subdirectory -
26 matches
Mail list logo