[Cmake-commits] CMake branch, master, updated. v3.13.2-752-gbc789af

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  bc789afac9215ea60069393e3a2af4afb149a84c (commit)
  from  fa9853d833a10aeb8ea94abb98c0ebe3d7dfe5be (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=bc789afac9215ea60069393e3a2af4afb149a84c
commit bc789afac9215ea60069393e3a2af4afb149a84c
Author: Kitware Robot 
AuthorDate: Thu Dec 20 00:01:05 2018 -0500
Commit: Kitware Robot 
CommitDate: Thu Dec 20 00:01:05 2018 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index ad26f61..3c4c065 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 13)
-set(CMake_VERSION_PATCH 20181219)
+set(CMake_VERSION_PATCH 20181220)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
https://cmake.org/mailman/listinfo/cmake-commits

[CMake] cmake cannot find source file (new to cmake)

[Cao, Lei via CMake]

Hi,


I tried to follow some examples and wrote some cmake files to build my 
code. But cmake is complaining that it cannot find a source file. Here is the 
code structure:


Toplevel

   |- CMakeLists.txt

   |- src |--CMakeLists.txt

   |  |--common---|---CMakeLists.txt

   |  |--dir1-|   |--- 
src1.h

   |  |-CMakeLists.txt

   |bin|-src2.c

  |-src3.c


Here is the CMakeLists.txt in toplevel:

project(proj)

add_subdirectory(src)



Here is the CMakeLists.txt in src:

project(proj)

add_subdirectory(common)

add_subdirectory(dir1)

include_directories(common)

set(src_files src1.h src2.c src3.c)

add_executable(exec ${src_files})


 CMakeLists.txt in common and dir1 are empty.


  When I ran "cmake .." in bin, cmake complained that it could not find 
source file src1.h in add_executable. What is wrong here?


Thanks,

Lei
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Kyle Edwards via cmake-developers]

On Tue, 2018-12-18 at 20:53 -0500, frodak17 wrote:
> I have thought about it which is why I asked.  The original
> assumption of one toolchain per CMake project is being extended. So
> why not think of extending the build type.  Sure it's simpler to
> ignore the build type. However, it doesn't make sense to me to build
> and run a host tool in debug mode when it could be running faster if
> built in release mode.  This is independent of whatever I'm doing
> with cross-compiler targets. You're already updating the generator to
> pick and choose the proper flags just on the tool chain type and it
> already picks the correct flags based on the configuration type.  But
> instead of the generator looking at the global build type it looks at
> the target build type. The target build type could default to the
> global build type and be overridden via a property.
> 
> Multi config generators would be problematic if they don't have a
> Configuration Manager that allows for setting different projects with
> different configurations (like Visual Studio) but is that reason
> enough to exclude the idea for single configuration generators?
I suppose we could consider the idea of supporting this separation for
single-config generators, but I can't think of a good way to make it
work for multi-config generators.
> If this can already be simply done why is anyone asking to use multiple 
> toolchains in a single project?  You just use an ExternalProject with each 
> toolchain file and you're done, or is this a shortcut method instead of using 
> ExternalProject to build the host tool?
You can use ExternalProject, but it's a bit like using a chainsaw when
all you need is a scalpel. Multi-toolchain would make it easy to keep
host tools and target code in the same project in the *simple* case
(like the Linux kernel example I gave in a previous email.) If you want
to do something more complicated then ExternalProject would be your
best bet.
Kyle-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake-developers

Re: [cmake-developers] Idea for Multi-Toolchain Support

[Wouter Klouwen]

Hello,

just chiming in here. I work for a company that works with embedded
devices, so cross compiling is our bread and butter.

We have a super build system - in a combination of CMake and Makefile -
that first builds a certain set of projects for the host platform and
second builds for the actual target platform.
For testing purposes we can also build all projects for the host
platform to run tests.
All of the projects are compiled through ExternalProject, as it's a mix
of open source packages which can use arbitrary build systems and our
own projects, which use CMake.

Within our own projects we already have a set of functions that wrap
add_executable() and add_library() to make our lives easier and enforce
common idioms so adding some multiple toolchains there would be easy.
The open source packages would be a bit trickier as we'd have to ensure
that with the ExternalProject calls it would use the correct toolchain
given a CMake toolchain definition that would then have to apply to a
non CMake build system such as automake.

However, we don't just have one target platform, we have more than 5
combined ARM and MIPS platforms all with different gcc versions, etc,
along with the host build. Each different platform may have a different
set of projects enabled. This depends on a great number of variables,
like hardware support, etc., as well as non technical reasons.

If there was multiple toolchain support, we could squash the super build
system away which gives a bit more of an integrated system - great - but
the complexity of selecting the correct projects to build given a
certain platform would then have to be put somewhere else - not so great.

While I dislike the super build system concept, it does provide for an
abstraction of that complexity for some of these problems.

As we have adopted CMake wider and wider over the past few months, some
of the limitations have become clearer too, mainly the fact it runs on a
single thread.
We have over 400 individual projects with nearly 1000 CMakeLists.txt
files with a total of 27k lines of CMake.
I have performed some experiments to partially convert the super build
system to be purely CMake for the single stages, which was an
interesting exercise.
I found that the process from parsing the CMake files to generating the
50MB worth of build.ninja file took over 30 seconds on an i7 CPU with
SATA SSDs.
If this was further extended to include both host and target that would
result in an even slower build file generation.

The super build system concept helps us here too as by splitting the
parsing of CMakeLists.txt up with ExternalProject the overall generation
of the build.ninja file takes a "mere" ~7 seconds.

This limitation alone means that doing any of this could be really
detrimental to the iterative build cycle and would severely limit the
usability of this feature for us.

W

On 19/12/2018 05:05, Peter Mitrano wrote:
> [External email]
>
> Hey all, just thought I would chime in and note that I very often write
> code that I expect to run both on my robots hardware and on my
> development machine in a simulator. In this case, I want the same target
> names and everything -- I simply use two cmake build directories, and
> now there is even support for this workflow in CLion so my life is very
> easy. Doing all of those as two targets with distinct names would be
> cumbersome, and the current system works very well for me.
>
> On Tue, Dec 18, 2018 at 8:54 PM frodak17  > wrote:
>
>
>
> On Tue, Dec 18, 2018 at 4:41 PM Kyle Edwards
> mailto:kyle.edwa...@kitware.com>> wrote:
>
> On Tue, 2018-12-18 at 16:12 -0500, frodak17 wrote:
>> What about conflicting build types when building a host tool
>> target vs the cross compiler target?
>> For instance the host tool may (should?) be built as a release
>> project (default optimization levels) but the cross compiler
>> project could be built as a debug project (so you can debug it
>> with no optimizations)?
>> I guess it would then be CMAKE__BUILD_TYPE and then
>> targets using that toolchain would be built with that build type.
>
> I think that both host and cross targets would be built with the
> same build type. If you're using a multi-config generator like
> VS or Xcode, how do you specify which combination of configs you
> want? It's simpler if every target is built as the same type,
> whether it's host or cross. Think about it - the current system
> already expects that every target in the project is built as the
> same build type. There's no way to specify "foo is built as
> debug, bar is built as release." Why would this assumption
> change just because we add a multi-toolchain mechanic?
>
>
> I have thought about it which is why I asked.  The original
> assumption of one toolchain per CMake project is being extended. So
>   

[Cmake-commits] CMake branch, master, updated. v3.13.2-751-gfa9853d

[Kitware Robot via Cmake-commits]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  fa9853d833a10aeb8ea94abb98c0ebe3d7dfe5be (commit)
   via  b2aa3aedeab09ad7b2c95353d2d3c3d867bcec53 (commit)
   via  32cb564bea57af007d03fa31d80a0177057fc901 (commit)
   via  7ffa6bf99972a980d995081a66b858eaaca9db7e (commit)
  from  e4c5e81f3116f620104d377b78e718ee47723125 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=fa9853d833a10aeb8ea94abb98c0ebe3d7dfe5be
commit fa9853d833a10aeb8ea94abb98c0ebe3d7dfe5be
Merge: e4c5e81 b2aa3ae
Author: Kyle Edwards 
AuthorDate: Wed Dec 19 17:02:19 2018 +
Commit: Kitware Robot 
CommitDate: Wed Dec 19 12:02:27 2018 -0500

Merge topic 'member-init'

b2aa3aedea clang-tidy: Use default member initialization
32cb564bea clang-tidy: Remove redundant member initializations
7ffa6bf999 cmUVHandlePtr: Use inherited constructors

Acked-by: Kitware Robot 
Merge-request: !2726


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b2aa3aedeab09ad7b2c95353d2d3c3d867bcec53
commit b2aa3aedeab09ad7b2c95353d2d3c3d867bcec53
Author: Regina Pfeifer 
AuthorDate: Wed Nov 21 23:17:54 2018 +0100
Commit: Regina Pfeifer 
CommitDate: Sat Dec 15 10:52:37 2018 +0100

clang-tidy: Use default member initialization

diff --git a/.clang-tidy b/.clang-tidy
index 20f1bf1..dc60714 100644
--- a/.clang-tidy
+++ b/.clang-tidy
@@ -15,7 +15,6 @@ modernize-*,\
 -modernize-raw-string-literal,\
 -modernize-return-braced-init-list,\
 -modernize-use-auto,\
--modernize-use-default-member-init,\
 -modernize-use-emplace,\
 -modernize-use-equals-default,\
 -modernize-use-equals-delete,\
@@ -36,4 +35,7 @@ readability-*,\
 -readability-simplify-boolean-expr,\
 "
 HeaderFilterRegex: 'Source/cm[^/]*\.(h|hxx|cxx)$'
+CheckOptions:
+  - key:   modernize-use-default-member-init.UseAssignment
+value: '1'
 ...
diff --git a/Source/CTest/cmCTestBuildHandler.cxx 
b/Source/CTest/cmCTestBuildHandler.cxx
index a8309d9..539a0ce 100644
--- a/Source/CTest/cmCTestBuildHandler.cxx
+++ b/Source/CTest/cmCTestBuildHandler.cxx
@@ -503,10 +503,7 @@ public:
 : FTC(ftc)
   {
   }
-  FragmentCompare()
-: FTC(nullptr)
-  {
-  }
+  FragmentCompare() {}
   bool operator()(std::string const& l, std::string const& r) const
   {
 // Order files by modification time.  Use lexicographic order
@@ -520,7 +517,7 @@ public:
   }
 
 private:
-  cmFileTimeComparison* FTC;
+  cmFileTimeComparison* FTC = nullptr;
 };
 
 void cmCTestBuildHandler::GenerateXMLLaunched(cmXMLWriter& xml)
diff --git a/Source/CTest/cmCTestGIT.cxx b/Source/CTest/cmCTestGIT.cxx
index 471ab88..4ede3d4 100644
--- a/Source/CTest/cmCTestGIT.cxx
+++ b/Source/CTest/cmCTestGIT.cxx
@@ -475,13 +475,9 @@ private:
   {
 std::string Name;
 std::string EMail;
-unsigned long Time;
-long TimeZone;
-Person()
-  : Time(0)
-  , TimeZone(0)
-{
-}
+unsigned long Time = 0;
+long TimeZone = 0;
+Person() {}
   };
 
   void ParsePerson(const char* str, Person& person)
diff --git a/Source/cmCPluginAPI.cxx b/Source/cmCPluginAPI.cxx
index 22ae340..065a184 100644
--- a/Source/cmCPluginAPI.cxx
+++ b/Source/cmCPluginAPI.cxx
@@ -475,11 +475,8 @@ int CCONV cmGetTotalArgumentSize(int argc, char** argv)
 // API for source files.
 struct cmCPluginAPISourceFile
 {
-  cmCPluginAPISourceFile()
-: RealSourceFile(nullptr)
-  {
-  }
-  cmSourceFile* RealSourceFile;
+  cmCPluginAPISourceFile() {}
+  cmSourceFile* RealSourceFile = nullptr;
   std::string SourceName;
   std::string SourceExtension;
   std::string FullPath;
diff --git a/Source/cmCTest.h b/Source/cmCTest.h
index 7da0e1d..480204a 100644
--- a/Source/cmCTest.h
+++ b/Source/cmCTest.h
@@ -57,10 +57,7 @@ public:
   /** Representation of one part.  */
   struct PartInfo
   {
-PartInfo()
-  : Enabled(false)
-{
-}
+PartInfo() {}
 
 void SetName(const std::string& name) { this->Name = name; }
 const std::string& GetName() const { return this->Name; }
@@ -71,7 +68,7 @@ public:
 std::vector SubmitFiles;
 
   private:
-bool Enabled;
+bool Enabled = false;
 std::string Name;
   };
 #ifdef CMAKE_BUILD_WITH_CMAKE
diff --git a/Source/cmCacheManager.h b/Source/cmCacheManager.h
index a269271..b39856e 100644
--- a/Source/cmCacheManager.h
+++ b/Source/cmCacheManager.h
@@ -34,20 +34,15 @@ private:
   struct CacheEntry
   {
 std::string Value;
-cmStateEnums::CacheEntryType Type;
+cmStateEnums::CacheEntryType Type = cmStateEnums::UNINITIALIZED;
 cmPropertyMap Properties;
 std::vector GetPropertyList() const;
 const char* GetProperty(const 

Re: [CMake] Modern cmake advise for transitive library dependencies

[Roger Leigh]

On 18/12/2018 20:54, Craig Scott wrote:


Your XConfig.cmake is responsible for also ensuring all targets it 
depends on are defined. This shouldn't be left up to consumers of X. The 
way this is normally done is pretty much as Alan suggests (it's also the 
way I handle cases analogous to yours in our projects at work). There's 
even a find_dependency() 
 
command intended for precisely this situation to make it a little 
easier, although I generally advise against using it for packages that 
support components due to the way a particular optimisation in its 
implementation affects later find_dependency() calls for the same package.


Can't we drop this optimisation and fix find_dependency, making it 
properly usable?  I've tested a few of the modules using components to 
see if they behave correctly with different sets of components, and I've 
not yet encountered any problems due to calling multiple times.


In consequence, I wonder if we could simply drop the "optimisation" and 
have find_dependency do nothing more than be a thin wrapper around
find_package.  This would solve the problems and should not break 
backward compatibility.


The only difference would be if the first find_package call succeeds and 
subsequent calls fail, which would alter the value of _FOUND.  However,

that's likely exactly what one should expect.


Regards,
Roger
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake