[Cmake-commits] CMake branch, master, updated. v3.11.1-703-g135825d

[Kitware Robot]

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  135825df209db1375f60c44b14dbceb362e8d5aa (commit)
  from  e628d6cd066774e4c95ec368fc6ef0be731ff0a5 (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=135825df209db1375f60c44b14dbceb362e8d5aa
commit 135825df209db1375f60c44b14dbceb362e8d5aa
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sat May 5 00:01:06 2018 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sat May 5 00:01:06 2018 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index cf91298..280fe6d 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 11)
-set(CMake_VERSION_PATCH 20180504)
+set(CMake_VERSION_PATCH 20180505)
 #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

Re: [CMake] Memory usage and configuration time for large project

[Isaiah Norton]

As one ballpark datapoint: a "superbuild" of 3D Slicer (slicer.org) has a
similar object and library count:

macbook-pro:s5nj inorton$ find ./ -name *.o | wc -l
>14127

macbook-pro:s5nj inorton$ find ./ -name *.dylib -or -name *.so | wc -l
> 2158


Based on a few quick tests, the aggregate cmake time is probably about 6-8
minutes for the ninja generator, over the multi-hour build (each dependency
is configured and built as a separate sub-project via CMake's
ExternalProject mechanism) -- with the caveat that each of those cmake runs
is doing lengthy checks that should only be done once if your project
strictly uses `add_subdirectory`.

As a more concrete point of comparison, building VTK generates 5747 object
files, and a clean configure on my 2-core macbook takes about 90s.

Isaiah



On Fri, May 4, 2018 at 2:16 PM, Patrick E Gartung  wrote:

> Just to be clear, the memory and time used are just to configure and
> generate the makefiles or Ninja file. The build itself can take several
> hours.
>
> On 4/30/18, 4:55 PM, "R0b0t1"  wrote:
>
> On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung 
> wrote:
> >  Hi,
> >
> > We have a large c/c++/fortran project, CMSSW, that is built with a
> custom tool, scram.
> >
> > https://github.com/cms-sw/cmssw
> >
> > The project might move to a cmake based build in the future. The
> scripts to convert to CmakeLists.tx has been written
> >
> > https://github.com/cms-sw/cmssw2cmake
> >
> > Tests show that with the cmake files generated with this script,
> configuring the project uses up to 1.5GB of ram and takes 11 minutes when
> using -GMakefiles. Using -GNinja and using the latest cmake, this time can
> be reduced to 8 minutes.
> >
> > The project builds 14k object files, 2.2k libraries, ~600 binaries,
> 500 generated source files with links to ~100 external libraries.
> >
> > Is this amount of memory usage and time typical for a project of
> this size?
> >
>
> I'm inclined to say "yes" as many builds such as Firefox, its
> supporting libraries, and Chrome all take lots of time and memory.
> Chrome uses Ninja, I might add. But the issue is not CMake itself.
> CMake tends to produce better builds.
>
> As I am not intimately familiar with your project, I can't make good
> concrete suggestions. You may enjoy reading
> https://news.ycombinator.com/item?id=14733829 and searching for build
> optimization strategies.
>
> Keep in mind a lot of the blame falls on C++ and Windows, should you
> be using Windows. If you aren't using Windows, then the advice in the
> comments above should still be relevant, and give you something to go
> on.
>
> Cheers,
>  R0b0t1
>
> > Patrick Gartung
> > Fermilab
> >
>
>
> --
>
> 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
>
>
-- 

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] Linking programs with Clang & OpenMP fails

[Kim Walisch]

Hi,

I have figured out what the problem is:

LLVM/Clang with OpenMP requires linking against libatomic only when
using 128-bit integers. The following program fails to compile using
Clang-6.0 on Ubuntu 18 x86_64 using:

$ clang++ -fopenmp=libomp test.cpp

#include 

int main() {
__int128_t sum = 0;

#pragma omp parallel for reduction(+: sum)
for (int i = 0; i < 100; i++)
sum += i;

return 0;
}

But it compiles fine when adding -latomic:
clang++ -fopenmp=libomp test.cpp -latomic

For me, this is neither a CMake bug nor an LLVM/Clang bug but it is
still very confusing as GCC does not require linking against libatomic.

Regards,
Kim

On Fri, May 4, 2018 at 7:48 PM, Kim Walisch  wrote:

> Hi,
>
> The latest Clang-6.0 compiler finally enables OpenMP by default on
> Linux (e.g. Ubuntu-18 x86_64).
>
> But OpenMP programs using Clang-6.0/CMake-3.10 fail to compile:
>
> [100%] Linking CXX executable primecount
> libprimecount.a(P2.cpp.o): In function `.omp_outlined..7':
> P2.cpp:(.text+0x2194): undefined reference to `__atomic_load'
> P2.cpp:(.text+0x21ef): undefined reference to `__atomic_compare_exchange'
> CMakeFiles/primecount.dir/build.make:148: recipe for target 'primecount'
> failed
> make[2]: *** [primecount] Error 1
>
> The problem is that:
>
> target_link_libraries(myprogram OpenMP::OpenMP_CXX)
>
> does not add libatomic to the linker options which LLVM/Clang's OpenMP
> library depends upon. When I manually add -latomic to the linker
> options my OpenMP programs compile & link fine using Clang-6.0/CMake-3.10.
>
> Regards,
> Kim
>
-- 

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] Why isn't target_link_libraries not enough in some cases?

[Craig Scott]

On Sat, May 5, 2018 at 1:33 AM, Francis Giraldeau <
francis.girald...@gmail.com> wrote:

> > Hi,
> >
> > I am fetching and building SDL2 using FetchContent and then using
> > target_link_libraries(MyExe SDL2) in the hopes that the required include
> > directories and libraries will be added populated properly. The example
> > project can be found here:
> >
> > https://github.com/samaursa/cmake_fetch_content_SDL2
> >
> > Unfortunately, it seems that I have to manually specify the include
> > directories. Although target_link_directories(...) does take care of the
> > linking against the correct libraries. When it comes to my own CMake
> > enabled libraries, I do not have to specify the include directories.
>
> The SDL add_library() only specify the include directory for install
> target:
>
>   target_link_libraries(SDL2 ${EXTRA_LIBS} ${EXTRA_LDFLAGS})
>   target_include_directories(SDL2 PUBLIC $ SDL2>)
>
> They themselves include directories using the old global includes instead
> of target specific includes:
>
>   include_directories(${SDL2_BINARY_DIR}/include
> ${SDL2_SOURCE_DIR}/include)
>
> There should be a target_include_directories(SDL2 PUBLIC
> <$BUILD_INTERFACE:${SDL2_SOURCE_DIR}/include), but that must be in the
> same CMakeLists that defines the library, which require changing the SDL's
> CMakeLists.
>


That's not actually true. You can call target_include_directories() on any
target, not just those created in the current scope. In fact, all of the
target_...() commands except target_link_libraries() can do this (and it
was recently agreed
 that we
should remove the restriction on target_link_libraries() too). This means
if a project like SDL fails to set INTERFACE properties for header search
paths, compiler defines, etc. you can add them yourself from outside the
project. Obviously it's better if the project itself can be updated to do
it, but in the meantime your own project can add the missing things.



>
> So, one solution could be to create an imported target to attach this path
> and l ink to it instead:
>
>   add_library(SDL2x INTERFACE IMPORTED)
>   set_target_properties(SDL2x PROPERTIES INTERFACE_INCLUDE_DIRECTORIES
> "${sdl2_SOURCE_DIR}/include")
>   set_target_properties(SDL2x PROPERTIES INTERFACE_LINK_LIBRARIES SDL2)
>
> Tested with CMake 3.11. However, to make it work, I had to add OpenGL:
>
>   find_package(OpenGL REQUIRED)
>   target_link_libraries(testExe SDL2x OpenGL::GL)
>

> Install fails, but that's another issue (the symlink is created in the
> wrong directory) and this should be reported to SDL I guess.
>
> CMake Error at _deps/sdl2-build/cmake_install.cmake:188 (file):
>   file INSTALL cannot find
>   "[...]/build/_deps/sdl2-build/libSDL2.so".
> Call Stack (most recent call first):
>   cmake_install.cmake:42 (include)
>
>
-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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] Memory usage and configuration time for large project

[Patrick E Gartung]

Just to be clear, the memory and time used are just to configure and generate 
the makefiles or Ninja file. The build itself can take several hours.

On 4/30/18, 4:55 PM, "R0b0t1"  wrote:

On Mon, Apr 30, 2018 at 4:44 PM, Patrick E Gartung  wrote:
>  Hi,
>
> We have a large c/c++/fortran project, CMSSW, that is built with a custom 
tool, scram. 
>
> https://github.com/cms-sw/cmssw
>
> The project might move to a cmake based build in the future. The scripts 
to convert to CmakeLists.tx has been written
>
> https://github.com/cms-sw/cmssw2cmake
>
> Tests show that with the cmake files generated with this script, 
configuring the project uses up to 1.5GB of ram and takes 11 minutes when using 
-GMakefiles. Using -GNinja and using the latest cmake, this time can be reduced 
to 8 minutes.
>
> The project builds 14k object files, 2.2k libraries, ~600 binaries, 500 
generated source files with links to ~100 external libraries.
>
> Is this amount of memory usage and time typical for a project of this 
size?
>

I'm inclined to say "yes" as many builds such as Firefox, its
supporting libraries, and Chrome all take lots of time and memory.
Chrome uses Ninja, I might add. But the issue is not CMake itself.
CMake tends to produce better builds.

As I am not intimately familiar with your project, I can't make good
concrete suggestions. You may enjoy reading
https://news.ycombinator.com/item?id=14733829 and searching for build
optimization strategies.

Keep in mind a lot of the blame falls on C++ and Windows, should you
be using Windows. If you aren't using Windows, then the advice in the
comments above should still be relevant, and give you something to go
on.

Cheers,
 R0b0t1

> Patrick Gartung
> Fermilab
>



smime.p7s
Description: S/MIME cryptographic signature
-- 

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

[CMake] Linking programs with Clang & OpenMP fails

[Kim Walisch]

Hi,

The latest Clang-6.0 compiler finally enables OpenMP by default on
Linux (e.g. Ubuntu-18 x86_64).

But OpenMP programs using Clang-6.0/CMake-3.10 fail to compile:

[100%] Linking CXX executable primecount
libprimecount.a(P2.cpp.o): In function `.omp_outlined..7':
P2.cpp:(.text+0x2194): undefined reference to `__atomic_load'
P2.cpp:(.text+0x21ef): undefined reference to `__atomic_compare_exchange'
CMakeFiles/primecount.dir/build.make:148: recipe for target 'primecount'
failed
make[2]: *** [primecount] Error 1

The problem is that:

target_link_libraries(myprogram OpenMP::OpenMP_CXX)

does not add libatomic to the linker options which LLVM/Clang's OpenMP
library depends upon. When I manually add -latomic to the linker
options my OpenMP programs compile & link fine using Clang-6.0/CMake-3.10.

Regards,
Kim
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.11.1-702-ge628d6c

[Kitware Robot]

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  e628d6cd066774e4c95ec368fc6ef0be731ff0a5 (commit)
   via  3f315dc12878232f3f250d6f3c9959bee932941f (commit)
  from  5e5ef61ed3b5808dfe1a71623ec12c451d7fe385 (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=e628d6cd066774e4c95ec368fc6ef0be731ff0a5
commit e628d6cd066774e4c95ec368fc6ef0be731ff0a5
Merge: 5e5ef61 3f315dc
Author: Brad King 
AuthorDate: Fri May 4 15:25:39 2018 +
Commit: Kitware Robot 
CommitDate: Fri May 4 11:26:36 2018 -0400

Merge topic 'vs-refactor-xml'

3f315dc128 cmVisualStudio10TargetGenerator: XML refactoring

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=3f315dc12878232f3f250d6f3c9959bee932941f
commit 3f315dc12878232f3f250d6f3c9959bee932941f
Author: Vitaly Stakhovsky 
AuthorDate: Wed May 2 11:17:00 2018 -0400
Commit: Brad King 
CommitDate: Fri May 4 10:46:11 2018 -0400

cmVisualStudio10TargetGenerator: XML refactoring

diff --git a/Source/cmVisualStudio10TargetGenerator.cxx 
b/Source/cmVisualStudio10TargetGenerator.cxx
index 5497469..7a7c647 100644
--- a/Source/cmVisualStudio10TargetGenerator.cxx
+++ b/Source/cmVisualStudio10TargetGenerator.cxx
@@ -132,16 +132,16 @@ public:
   // if there are configuration specific flags, then
   // use the configuration specific tag for PreprocessorDefinitions
   this->TargetGenerator->WritePlatformConfigTag(
-tag, this->GetConfiguration(), indent);
+tag, this->GetConfiguration(), indent, content);
 } else {
   fout.fill(' ');
   fout.width(indent * 2);
   // write an empty string to get the fill level indent to print
   fout << "";
   fout << "<" << tag << ">";
+  fout << cmVS10EscapeXML(content);
+  fout << "\n";
 }
-fout << cmVS10EscapeXML(content);
-fout << "\n";
   }
 
 private:
@@ -276,7 +276,7 @@ std::string cmVisualStudio10TargetGenerator::CalcCondition(
 
 void cmVisualStudio10TargetGenerator::WritePlatformConfigTag(
   const char* tag, const std::string& config, int indentLevel,
-  const char* attribute)
+  const std::string& content)
 {
   std::ostream& stream = *this->BuildFileStream;
   stream.fill(' ');
@@ -285,14 +285,8 @@ void 
cmVisualStudio10TargetGenerator::WritePlatformConfigTag(
   stream << "<" << tag << " Condition=\"";
   stream << this->CalcCondition(config);
   stream << "\"";
-  if (attribute) {
-stream << attribute;
-  }
-  // close the tag
-  stream << ">";
-  if (attribute) {
-stream << "\n";
-  }
+  stream << ">" << cmVS10EscapeXML(content);
+  stream << "\n";
 }
 
 std::ostream& cmVisualStudio10TargetGenerator::Elem::WriteString(
@@ -386,233 +380,236 @@ void cmVisualStudio10TargetGenerator::Generate()
   // Write the encoding header into the file
   char magic[] = { char(0xEF), char(0xBB), char(0xBF) };
   this->BuildFileStream->write(magic, 3);
+  (*this->BuildFileStream) << "GlobalGenerator->Encoding() + "\"?>\n";
 
+  Elem e0(*this->BuildFileStream, 0);
+  e0.StartElement("Project");
+  e0.Attribute("DefaultTargets", "Build");
   // get the tools version to use
   const std::string toolsVer(this->GlobalGenerator->GetToolsVersion());
-  std::string project_defaults = "GlobalGenerator->Encoding() + "\"?>\n";
-  project_defaults.append("http://schemas.microsoft.com/developer/msbuild/2003\;>\n");
-  this->WriteString(project_defaults.c_str(), 0);
+  e0.Attribute("ToolsVersion", toolsVer);
+  e0.Attribute("xmlns", "http://schemas.microsoft.com/developer/msbuild/2003;);
+  e0.SetHasElements();
 
   if (this->NsightTegra) {
-this->WriteString("\n", 1);
+Elem e1(e0, "PropertyGroup");
+e1.Attribute("Label", "NsightTegraProject");
 const unsigned int nsightTegraMajorVersion = this->NsightTegraVersion[0];
 const unsigned int nsightTegraMinorVersion = this->NsightTegraVersion[1];
 if (nsightTegraMajorVersion >= 2) {
-  this->WriteString("", 2);
   if (nsightTegraMajorVersion > 3 ||
   (nsightTegraMajorVersion == 3 && nsightTegraMinorVersion >= 1)) {
-(*this->BuildFileStream) << "11";
+e1.Element("NsightTegraProjectRevisionNumber", "11");
   } else {
 // Nsight Tegra 2.0 uses project revision 9.
-(*this->BuildFileStream) << "9";
+e1.Element("NsightTegraProjectRevisionNumber", "9");
   }
-  (*this->BuildFileStream) << "\n";
   // Tell newer versions to upgrade silently when loading.
-  

Re: [CMake] Why isn't target_link_libraries not enough in some cases?

[Francis Giraldeau]

> Hi,
>
> I am fetching and building SDL2 using FetchContent and then using
> target_link_libraries(MyExe SDL2) in the hopes that the required include
> directories and libraries will be added populated properly. The example
> project can be found here:
>
> https://github.com/samaursa/cmake_fetch_content_SDL2
>
> Unfortunately, it seems that I have to manually specify the include
> directories. Although target_link_directories(...) does take care of the
> linking against the correct libraries. When it comes to my own CMake
> enabled libraries, I do not have to specify the include directories.

The SDL add_library() only specify the include directory for install
target:

  target_link_libraries(SDL2 ${EXTRA_LIBS} ${EXTRA_LDFLAGS})
  target_include_directories(SDL2 PUBLIC $)

They themselves include directories using the old global includes instead
of target specific includes:

  include_directories(${SDL2_BINARY_DIR}/include ${SDL2_SOURCE_DIR}/include)

There should be a target_include_directories(SDL2 PUBLIC
<$BUILD_INTERFACE:${SDL2_SOURCE_DIR}/include), but that must be in the same
CMakeLists that defines the library, which require changing the SDL's
CMakeLists.

So, one solution could be to create an imported target to attach this path
and l ink to it instead:

  add_library(SDL2x INTERFACE IMPORTED)
  set_target_properties(SDL2x PROPERTIES INTERFACE_INCLUDE_DIRECTORIES
"${sdl2_SOURCE_DIR}/include")
  set_target_properties(SDL2x PROPERTIES INTERFACE_LINK_LIBRARIES SDL2)

Tested with CMake 3.11. However, to make it work, I had to add OpenGL:

  find_package(OpenGL REQUIRED)
  target_link_libraries(testExe SDL2x OpenGL::GL)

Install fails, but that's another issue (the symlink is created in the
wrong directory) and this should be reported to SDL I guess.

CMake Error at _deps/sdl2-build/cmake_install.cmake:188 (file):
  file INSTALL cannot find
  "[...]/build/_deps/sdl2-build/libSDL2.so".
Call Stack (most recent call first):
  cmake_install.cmake:42 (include)

Francis
-- 
Francis Giraldeau
-- 

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

[Cmake-commits] CMake branch, master, updated. v3.11.1-700-g5e5ef61

[Kitware Robot]

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  5e5ef61ed3b5808dfe1a71623ec12c451d7fe385 (commit)
   via  828e18bb3eadaff9bbe8b1ddf57b68cf40e0eafb (commit)
  from  fc35e817ee243d31c5846d09b0b21f2756a0727b (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=5e5ef61ed3b5808dfe1a71623ec12c451d7fe385
commit 5e5ef61ed3b5808dfe1a71623ec12c451d7fe385
Merge: fc35e81 828e18b
Author: Brad King 
AuthorDate: Fri May 4 15:04:43 2018 +
Commit: Kitware Robot 
CommitDate: Fri May 4 11:04:53 2018 -0400

Merge topic 'doc-xref-envvar'

828e18bb3e cmRST: Add support for 'envvar' cmake domain role

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=828e18bb3eadaff9bbe8b1ddf57b68cf40e0eafb
commit 828e18bb3eadaff9bbe8b1ddf57b68cf40e0eafb
Author: Brad King 
AuthorDate: Thu May 3 14:34:32 2018 -0400
Commit: Brad King 
CommitDate: Fri May 4 07:52:14 2018 -0400

cmRST: Add support for 'envvar' cmake domain role

This was accidentally left out of commit 8acf46caf1 (Utilities/Sphinx:
Add role and directive for 'envvar' in CMake domain, 2018-04-19).

diff --git a/Source/cmRST.cxx b/Source/cmRST.cxx
index 112be4d..edcbc22 100644
--- a/Source/cmRST.cxx
+++ b/Source/cmRST.cxx
@@ -34,7 +34,7 @@ cmRST::cmRST(std::ostream& os, std::string const& docroot)
   , NoteDirective("^.. note::[ \t]*(.*)$")
   , ModuleRST("^#\\[(=*)\\[\\.rst:$")
   , CMakeRole("(:cmake)?:("
-  "command|generator|variable|module|policy|"
+  "command|generator|variable|envvar|module|policy|"
   "prop_cache|prop_dir|prop_gbl|prop_inst|prop_sf|"
   "prop_test|prop_tgt|"
   "manual"
diff --git a/Tests/CMakeLib/testRST.expect b/Tests/CMakeLib/testRST.expect
index fa436cb..4b29762 100644
--- a/Tests/CMakeLib/testRST.expect
+++ b/Tests/CMakeLib/testRST.expect
@@ -16,6 +16,8 @@ Variable ``_VARIABLE`` with leading placeholder.
 Variable ``VARIABLE_`` with trailing placeholder.
 Variable ``_VARIABLE`` with leading placeholder and target.
 Variable ``VARIABLE_`` with trailing placeholder and target.
+Environment variable ``SOME_ENV_VAR``.
+Environment variable ``some env var`` with space and target.
 Generator ``Some Generator`` with space.
 
 First TOC entry.
diff --git a/Tests/CMakeLib/testRST.rst b/Tests/CMakeLib/testRST.rst
index 54952dd..9cd7257 100644
--- a/Tests/CMakeLib/testRST.rst
+++ b/Tests/CMakeLib/testRST.rst
@@ -23,6 +23,8 @@ Variable :variable:`_VARIABLE` with leading 
placeholder.
 Variable :variable:`VARIABLE_` with trailing placeholder.
 Variable :variable:`_VARIABLE ` with leading placeholder 
and target.
 Variable :variable:`VARIABLE_ ` with trailing placeholder 
and target.
+Environment variable :envvar:`SOME_ENV_VAR`.
+Environment variable :envvar:`some env var ` with space and 
target.
 Generator :generator:`Some Generator` with space.
 
 .. |not replaced| replace:: not replaced through toctree

---

Summary of changes:
 Source/cmRST.cxx  |2 +-
 Tests/CMakeLib/testRST.expect |2 ++
 Tests/CMakeLib/testRST.rst|2 ++
 3 files changed, 5 insertions(+), 1 deletion(-)


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

[Cmake-commits] CMake branch, master, updated. v3.11.1-698-gfc35e81

[Kitware Robot]

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  fc35e817ee243d31c5846d09b0b21f2756a0727b (commit)
   via  efaaa729aa1c4ab2c351e7fb5ed5ea8712957db8 (commit)
   via  46fa1af5142e72558fcd378e12f7ec7d7ee3c90d (commit)
   via  4f82199befee194aa924fd4dcdb2f4aad1f7dab6 (commit)
  from  c89d2f4a6ae3e6cb0f87493cac3f5f723bb4f62e (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=fc35e817ee243d31c5846d09b0b21f2756a0727b
commit fc35e817ee243d31c5846d09b0b21f2756a0727b
Merge: efaaa72 46fa1af
Author: Brad King 
AuthorDate: Fri May 4 13:35:51 2018 +
Commit: Kitware Robot 
CommitDate: Fri May 4 09:37:14 2018 -0400

Merge topic 'test-CheckSourceTree-in-source'

46fa1af514 Tests: Fix CheckSourceTree for in-source non-dashboard builds

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=efaaa729aa1c4ab2c351e7fb5ed5ea8712957db8
commit efaaa729aa1c4ab2c351e7fb5ed5ea8712957db8
Merge: c89d2f4 4f82199
Author: Brad King 
AuthorDate: Fri May 4 13:35:32 2018 +
Commit: Kitware Robot 
CommitDate: Fri May 4 09:36:08 2018 -0400

Merge topic 'genex-complang-not-loaded'

4f82199bef Genex: Allow COMPILE_LANGUAGE to name a language that is not 
loaded

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


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46fa1af5142e72558fcd378e12f7ec7d7ee3c90d
commit 46fa1af5142e72558fcd378e12f7ec7d7ee3c90d
Author: Israel Blancas 
AuthorDate: Tue May 1 20:23:05 2018 +0200
Commit: Brad King 
CommitDate: Thu May 3 09:35:45 2018 -0400

Tests: Fix CheckSourceTree for in-source non-dashboard builds

For in-source builds we must tolerate non-tracked files in the
source tree.  Previously we only tolerated them for dashboard
builds during automated testing, but we should tolerate them for
local user builds too.

Fixes: #17868

diff --git a/Tests/CMakeTests/CheckSourceTreeTest.cmake.in 
b/Tests/CMakeTests/CheckSourceTreeTest.cmake.in
index 8145db7..4f2aaea 100644
--- a/Tests/CMakeTests/CheckSourceTreeTest.cmake.in
+++ b/Tests/CMakeTests/CheckSourceTreeTest.cmake.in
@@ -308,13 +308,11 @@ 
message("===
 if("$ENV{DASHBOARD_TEST_FROM_CTEST}" STREQUAL "")
 
   # developers are allowed to have local additions and modifications...
-  set(is_dashboard 0)
   message("interactive test run")
   message("")
 
 else()
 
-  set(is_dashboard 1)
   message("dashboard test run")
   message("")
 
@@ -341,7 +339,7 @@ endif()
 # Not even developers.
 #
 if(nonadditions)
-  if(in_source_build AND is_dashboard)
+  if(in_source_build)
 message("
 warning: test results confounded because this is an 'in-source' build - cannot
 distinguish between non-added files that are in-source build products and

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4f82199befee194aa924fd4dcdb2f4aad1f7dab6
commit 4f82199befee194aa924fd4dcdb2f4aad1f7dab6
Author: Henry Schreiner 
AuthorDate: Wed May 2 17:51:05 2018 -0400
Commit: Brad King 
CommitDate: Thu May 3 08:34:39 2018 -0400

Genex: Allow COMPILE_LANGUAGE to name a language that is not loaded

Evaluate to false on `$` if language `Lang`
is not loaded.  This is helpful in exported targets consumed in other
projects that may not enable all the same languages.

Fixes: #17952

diff --git a/Source/cmGeneratorExpressionNode.cxx 
b/Source/cmGeneratorExpressionNode.cxx
index 399e894..7b35bce 100644
--- a/Source/cmGeneratorExpressionNode.cxx
+++ b/Source/cmGeneratorExpressionNode.cxx
@@ -1013,16 +1013,7 @@ static const struct CompileLanguageNode : public 
cmGeneratorExpressionNode
   return std::string();
 }
 
-std::vector enabledLanguages;
 cmGlobalGenerator* gg = context->LG->GetGlobalGenerator();
-gg->GetEnabledLanguages(enabledLanguages);
-if (!parameters.empty() &&
-std::find(enabledLanguages.begin(), enabledLanguages.end(),
-  parameters.front()) == enabledLanguages.end()) {
-  reportError(context, content->GetOriginalExpression(),
-  "$ Unknown language.");
-  return std::string();
-}
 std::string genName = gg->GetName();
 if (genName.find("Makefiles") == std::string::npos &&
 genName.find("Ninja") == std::string::npos &&
diff 

[CMake] Install libraries defined in INTERFACE targets

[rozelak]

Hello,
I build a project which consists of several "modules" with various mutual 
dependencies. Each module defines its OBJECT target as:
 
 
    # Module 1:
    add_library(Module1 OBJECT )
    target_include_directories(Module1 PRIVATE ${CMAKE_CURRENT_SOURCE_DIR})
 
    add_library(Module1_LIBRARIES INTERFACE)
    target_link_libraries(Module1_LIBRARIES INTERFACE $)
 
 
    # Module 2:
    add_library(Module2 OBJECT )
    target_include_directories(Module2 PUBLIC 
$)
 
    add_library(Module2_LIBRARIES INTERFACE)
    target_link_libraries(Module2_LIBRARIES INTERFACE $ 
$)
 
    add_library(Module2_INCLUDES  INTERFACE)
    target_include_directories(Module2_INCLUDES  INTERFACE 
$)
    target_sources(Module2_INCLUDES  INTERFACE )
 
    add_library(Module_CONFFILE  INTERFACE)
    target_sources(Module2_CONFFILE  INTERFACE Module.config)
 
 
And when building a final product (or one of the final products), I use the 
individual targets:
 
    add_library(Product1 STATIC $ 
$ ...)
    target_link_libraries(Product1 LINK_INTERFACE_LIBRARIES 
$ $ ...)
 
 
 
It works perfectly, the library is built using all the sources. Even when 
defining INSTALL, all the properties of the targets (include files, config 
files, etc.) can be accessed and are installed correctly
 
    install(TARGETS Product1  DESTINATION "./" EXPORT "libProduct1")
    install(FILES $         
 DESTINATION "./config")
    install(FILES $         
 DESTINATION "./include")
 
    
The problem starts when I want to export a CMake file listing all the libraries 
which were defined by the individual modules (and are accessed by 
$) since they know what they need (how they 
were configured).
 
When building a static library (which is shown here), I need to export a list 
of additional libraries necessary to link the Product1 correctly. But using 
$ in the INSTALL() command does not work, 
neither works something like:
 
    install(EXPORT "llibProduct1" DESTINATION "." 
EXPORT_LINK_INTERFACE_LIBRARIES)
 
 
So the question is: how to export the libraries defined by the individual 
modules to an CMake file which would be installed together with the Product1 
library and header files?
 
 
Thank you very much,
Dan
 
P.S. I use CMake 3.6.2.
-- 

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