Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Elizabeth A. Fischer]

Well, I tried upstreaming the new build scripts to some projects and it
didn’t go well.
Some of the reasons I’ve heard of:

> I installed CMake 2.8.6 five years ago and I don’t want to update yet
> again!  People relying on old versions is quite common and any attempt
> to raise the min version will be frowned upon (see the discussion in
> the LLVM mailing lists for example).

Spack is really good at installing dependencies, and makes this a LOT
easier.  In your Spack recipe, you just tell it which version of CMake
your package needs.  If Spack hasn't already built that
version, it will download and install it for you.  Building packages by
hand, and configuring their dependencies, needs to go the way of stone
spears.

> We prefer to use autotools and don’t want to have to learn CMake.
> That’s fair. But also, no one likes to build an autotools backed
> project for Android or iOS.

I suppose it's fair.  But a Google search of "convert CMake to
Autotools" results in 9:1 stories of people abandoning Autotools for
CMake.  Except for the fact that it works well for users, I can't say
enough evil things about Autotools.

Part of the benefit of Autotools is it "just works" without
requiring the user to install anything.  This benefit is of little
value once you move to an auto-builder like Spack.  The days when
you can get any interesting software to work without installing
a zillion dependencies first are long gone.

> I’ve never heard of Spack before. It looks better than other solutions
> I’ve seen before.

The great and unique thing about Spack is it can install a zillion versions
of each package.  For example... if Package B uses MPI, I can build B-1.7
two (or more) times --- once with OpenMPI and once with MPICH.  And I can
install them side-by-side.  If you change any of the dependencies of a
package, Spack will see that as a new and separate version.  Most
auto-builders let you build one software distro, with only one build of
each package (or sometimes one build per numerical version of the package
or compiler or something).  Spack's versioning is a lot more powerful.

> But you still have to manage all the options from your build script

Not sure what you mean by this.  True, there is some redundancy building
code.  First you put the options and dependencies in a package's CMake
build.  And then you put them into the Spack build again.  Some things
could be simplified if we assumed our CMake-based packages would only ever
be built with Spack.  But we still need to create CMake-based software that
can be installed by hand.  Hence the redundancy between the CMake build
scripts and the Spack package.  In practice, this has not been the
end of the world.

Another nice thing about Spack is there is no difference between your
libraries and Third-party libraries.

> and publish the binaries somewhere.

In its original incarnation, Spack builds from source.  It does not publish
or install from binary distros (because the build you asked for, with all
its dependency variants, is likely not a build that's ever been built
before).  There's currently work on a project to use Spack to produce
binary RPMs, and maybe other forms of binary distribution.

> Then you need to teach your build scripts to get the right version.

Your build scripts know nothing about Spack.  Spack is an auto-builder that
sits ON TOP of your build scripts.

> I won’t trade my builds from source for a set of prebuilt binaries
anytime soon I think :)

Spack builds from source, it is not prebuilt binaries.

> > I don't think CMake is the best place to do it,
> Can you provide any details? I personally think that CMake is a
> natural and the only place where it should be done.

The most important reason here is because there are combinatorially
many versions of a package you COULD install, depending on what
versions of its dependencies you link with, and CMake provides nothing
to address that issue.  See here for an overview of how Spack
addresses the combinatorial versioning issue (which no other
auto-builder does, to the best of my knowledge):

http://hpcugent.github.io/easybuild/files/SC14_BoF_Spack.pdf

Once you've built something, it's nice to be able to re-use it.  If I
have a top-level CMake project that automatically builds three
dependencies, will other projects be able to make use of those
dependencies I've built?  Or do they become private?  If libraries
cannot be shared between applications, you will get a LOT of library
bloat, especially among the low-level libraries that get repeated
numerous times.  Admittedly, this may not be such an issue in some
environments where people are really only focused on building one
thing.

If you make a project, you might see it as a "top-level" project.  But
someone else might want to build something bigger on top of your work.  You
can never assume that "this package is top-level and no one will ever
depend on it."

Another obvious problem with using CMake for everything is that not
all packages 

[Cmake-commits] CMake branch, master, updated. v3.6.1-637-g65120d1

[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  65120d180b6e7658e296fd2c4c85a23f337c06dc (commit)
  from  e240a7c0176450e092e2398148c1e13f8940c239 (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=65120d180b6e7658e296fd2c4c85a23f337c06dc
commit 65120d180b6e7658e296fd2c4c85a23f337c06dc
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Wed Aug 17 00:01:04 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Wed Aug 17 00:01:04 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 8d950fd..ac1ae03 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 6)
-set(CMake_VERSION_PATCH 20160816)
+set(CMake_VERSION_PATCH 20160817)
 #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
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Private dependencies of static libraries exported as targets

[Nicholas Braden]

Ah, I misunderstood what you were asking about. It would be pretty
weird if CMake didn't know that static libraries always need all their
dependencies linked regardless of privacy, but I agree it should at
least be mentioned somewhere. My bad.

As for include path bloat, I cannot replicate this in my test project
- CMake will link all the dependencies as required but will NOT
violate "PRIVATE" for other things like include directories. Could you
give an example where you are seeing a static library's private
dependency's include path being added when linking the static library?

On Tue, Aug 16, 2016 at 7:44 PM, Ivan Shapovalov  wrote:
> TBH, I do not see the "PRIVATE dependencies are made PUBLIC for the
> purposes of linking when the dependent is static library" there.
>
> --
> Ivan Shapovalov / intelfx /
>
>
> On 2016-08-16 at 02:35 -0500, Nicholas Braden wrote:
>> Yes, the behavior is documented in several places, the most prominent
>> being here:
>> https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#t
>> ransitive-usage-requirements
>>
>>
>> On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov > e> wrote:
>> >
>> > On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote:
>> > >
>> > > As far as I know the PRIVATE
>> > > keyword
>> > > should have no effect on transitive linking when foo is static
>> > > and we
>> > > call:
>> > >
>> > > target_link_libraries(foo PRIVATE bar)
>> > >
>> > > Hope this helps.
>> >
>> > Wow. I did not know that. Should've tested on sample project.
>> > It does not solve include path bloat though, but that's a minor
>> > issue.
>> >
>> > One question remains... is this behavior documented somewhere?
>> >
>> > Anyway, huge thanks,
>> > --
>> Ivan Shapovalov / intelfx /
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Private dependencies of static libraries exported as targets

[Ivan Shapovalov]

TBH, I do not see the "PRIVATE dependencies are made PUBLIC for the
purposes of linking when the dependent is static library" there.

-- 
Ivan Shapovalov / intelfx /


On 2016-08-16 at 02:35 -0500, Nicholas Braden wrote:
> Yes, the behavior is documented in several places, the most prominent
> being here:
> https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#t
> ransitive-usage-requirements
> 
> 
> On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov  e> wrote:
> > 
> > On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote:
> > > 
> > > As far as I know the PRIVATE
> > > keyword
> > > should have no effect on transitive linking when foo is static
> > > and we
> > > call:
> > > 
> > > target_link_libraries(foo PRIVATE bar)
> > > 
> > > Hope this helps.
> > 
> > Wow. I did not know that. Should've tested on sample project.
> > It does not solve include path bloat though, but that's a minor
> > issue.
> > 
> > One question remains... is this behavior documented somewhere?
> > 
> > Anyway, huge thanks,
> > --
> Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

[Cmake-commits] CMake branch, next, updated. v3.6.1-1278-g662661b

[Daniel Pfeifer]

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, next has been updated
   via  662661b2b462946f8ba6c82af22f014a18619756 (commit)
   via  e7b842e18955d13f6d9c021bab4a8935bf282744 (commit)
  from  11d0fcfcfecdcef2e21a1acb550979d208e43aa0 (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=662661b2b462946f8ba6c82af22f014a18619756
commit 662661b2b462946f8ba6c82af22f014a18619756
Merge: 11d0fcf e7b842e
Author: Daniel Pfeifer 
AuthorDate: Tue Aug 16 19:50:25 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 19:50:25 2016 -0400

Merge topic 'readability-named-parameter' into next

e7b842e1 Make sure unnused parameters are /*named*/


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e7b842e18955d13f6d9c021bab4a8935bf282744
commit e7b842e18955d13f6d9c021bab4a8935bf282744
Author: Daniel Pfeifer 
AuthorDate: Wed Aug 17 01:49:57 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Wed Aug 17 01:49:57 2016 +0200

Make sure unnused parameters are /*named*/

diff --git a/Source/CPack/cmCPackArchiveGenerator.cxx 
b/Source/CPack/cmCPackArchiveGenerator.cxx
index b1f6864..9120a2f 100644
--- a/Source/CPack/cmCPackArchiveGenerator.cxx
+++ b/Source/CPack/cmCPackArchiveGenerator.cxx
@@ -259,7 +259,7 @@ int cmCPackArchiveGenerator::PackageFiles()
   return 1;
 }
 
-int cmCPackArchiveGenerator::GenerateHeader(std::ostream*)
+int cmCPackArchiveGenerator::GenerateHeader(std::ostream* /*unused*/)
 {
   return 1;
 }
diff --git a/Source/CPack/cpack.cxx b/Source/CPack/cpack.cxx
index 771519c..de572c0 100644
--- a/Source/CPack/cpack.cxx
+++ b/Source/CPack/cpack.cxx
@@ -50,7 +50,7 @@ static const char* cmDocumentationOptions[][2] = {
   { CM_NULLPTR, CM_NULLPTR }
 };
 
-int cpackUnknownArgument(const char*, void*)
+int cpackUnknownArgument(const char* /*unused*/, void* /*unused*/)
 {
   return 1;
 }
diff --git a/Source/CTest/cmCTestBZR.cxx b/Source/CTest/cmCTestBZR.cxx
index 0e08e1c..7baf7a3 100644
--- a/Source/CTest/cmCTestBZR.cxx
+++ b/Source/CTest/cmCTestBZR.cxx
@@ -19,7 +19,7 @@
 
 #include 
 
-extern "C" int cmBZRXMLParserUnknownEncodingHandler(void*,
+extern "C" int cmBZRXMLParserUnknownEncodingHandler(void* /*unused*/,
 const XML_Char* name,
 XML_Encoding* info)
 {
@@ -215,7 +215,7 @@ private:
 return true;
   }
 
-  void StartElement(const std::string& name, const char**) CM_OVERRIDE
+  void StartElement(const std::string& name, const char** /*atts*/) CM_OVERRIDE
   {
 this->CData.clear();
 if (name == "log") {
@@ -275,7 +275,7 @@ private:
 this->CData.clear();
   }
 
-  void ReportError(int, int, const char* msg) CM_OVERRIDE
+  void ReportError(int /*line*/, int /*column*/, const char* msg) CM_OVERRIDE
   {
 this->BZR->Log << "Error parsing bzr log xml: " << msg << "\n";
   }
diff --git a/Source/CTest/cmCTestBuildAndTestHandler.cxx 
b/Source/CTest/cmCTestBuildAndTestHandler.cxx
index eddbddc..9dab98a 100644
--- a/Source/CTest/cmCTestBuildAndTestHandler.cxx
+++ b/Source/CTest/cmCTestBuildAndTestHandler.cxx
@@ -123,14 +123,15 @@ int cmCTestBuildAndTestHandler::RunCMake(std::string* 
outstring,
   return 0;
 }
 
-void CMakeMessageCallback(const char* m, const char*, bool&, void* s)
+void CMakeMessageCallback(const char* m, const char* /*unused*/,
+  bool& /*unused*/, void* s)
 {
   std::string* out = (std::string*)s;
   *out += m;
   *out += "\n";
 }
 
-void CMakeProgressCallback(const char* msg, float, void* s)
+void CMakeProgressCallback(const char* msg, float /*unused*/, void* s)
 {
   std::string* out = (std::string*)s;
   *out += msg;
diff --git a/Source/CTest/cmCTestCurl.cxx b/Source/CTest/cmCTestCurl.cxx
index b335e32..6910f6f 100644
--- a/Source/CTest/cmCTestCurl.cxx
+++ b/Source/CTest/cmCTestCurl.cxx
@@ -54,8 +54,8 @@ static size_t curlWriteMemoryCallback(void* ptr, size_t size, 
size_t nmemb,
   return realsize;
 }
 
-static size_t curlDebugCallback(CURL*, curl_infotype, char* chPtr, size_t size,
-void* data)
+static size_t curlDebugCallback(CURL* /*unused*/, curl_infotype /*unused*/,
+char* chPtr, size_t size, void* data)
 {
   std::vector* vec = static_cast(data);
   vec->insert(vec->end(), chPtr, chPtr + size);
diff --git a/Source/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx 
b/Source/CTest/cmCTestEmptyBinaryDirectoryCommand.cxx
index 1bda9be..09ae1fc 100644
--- 

[Cmake-commits] CMake branch, next, updated. v3.6.1-1276-g11d0fcf

[Daniel Pfeifer]

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, next has been updated
   via  11d0fcfcfecdcef2e21a1acb550979d208e43aa0 (commit)
   via  a2af850ba6dbee7797484ec5f6696525123023fc (commit)
  from  bbafe31c4f905a77622f6da7307c05dba838ac80 (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=11d0fcfcfecdcef2e21a1acb550979d208e43aa0
commit 11d0fcfcfecdcef2e21a1acb550979d208e43aa0
Merge: bbafe31 a2af850
Author: Daniel Pfeifer 
AuthorDate: Tue Aug 16 19:09:24 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 19:09:24 2016 -0400

Merge topic 'include-what-you-use' into next

a2af850b fix a batch of include-what-you-use violations


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a2af850ba6dbee7797484ec5f6696525123023fc
commit a2af850ba6dbee7797484ec5f6696525123023fc
Author: Daniel Pfeifer 
AuthorDate: Wed Aug 17 01:08:13 2016 +0200
Commit: Daniel Pfeifer 
CommitDate: Wed Aug 17 01:08:13 2016 +0200

fix a batch of include-what-you-use violations

diff --git a/Source/CursesDialog/cmCursesCacheEntryComposite.h 
b/Source/CursesDialog/cmCursesCacheEntryComposite.h
index 8ed3902..c9c8238 100644
--- a/Source/CursesDialog/cmCursesCacheEntryComposite.h
+++ b/Source/CursesDialog/cmCursesCacheEntryComposite.h
@@ -14,6 +14,8 @@
 
 #include "cmCursesLabelWidget.h"
 
+class cmake;
+
 class cmCursesCacheEntryComposite
 {
 public:
diff --git a/Source/cmCacheManager.h b/Source/cmCacheManager.h
index 2331867..14e0f0a 100644
--- a/Source/cmCacheManager.h
+++ b/Source/cmCacheManager.h
@@ -17,6 +17,7 @@
 #include "cmPropertyMap.h"
 #include "cmState.h"
 
+class cmake;
 class cmMarkAsAdvancedCommand;
 
 /** \class cmCacheManager
diff --git a/Source/cmGhsMultiTargetGenerator.h 
b/Source/cmGhsMultiTargetGenerator.h
index 92a1109..118cae6 100644
--- a/Source/cmGhsMultiTargetGenerator.h
+++ b/Source/cmGhsMultiTargetGenerator.h
@@ -16,13 +16,13 @@
 
 #include "cmTarget.h"
 
+class cmCustomCommand;
 class cmGeneratedFileStream;
+class cmGeneratorTarget;
 class cmGlobalGhsMultiGenerator;
 class cmLocalGhsMultiGenerator;
 class cmMakefile;
 class cmSourceFile;
-class cmGeneratedFileStream;
-class cmCustomCommand;
 
 class cmGhsMultiTargetGenerator
 {
diff --git a/Source/cmState.cxx b/Source/cmState.cxx
index 0470508..d4eb90a 100644
--- a/Source/cmState.cxx
+++ b/Source/cmState.cxx
@@ -15,10 +15,19 @@
 #include "cmCacheManager.h"
 #include "cmCommand.h"
 #include "cmDefinitions.h"
+#include "cmListFileCache.h"
+#include "cmSystemTools.h"
+#include "cmTypeMacro.h"
 #include "cmVersion.h"
 #include "cmake.h"
 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 struct cmState::SnapshotDataType
 {
diff --git a/Source/cmState.h b/Source/cmState.h
index e5f9917..9ab4213 100644
--- a/Source/cmState.h
+++ b/Source/cmState.h
@@ -12,19 +12,25 @@
 #ifndef cmState_h
 #define cmState_h
 
-#include "cmStandardIncludes.h"
+#include  // IWYU pragma: keep
 
 #include "cmAlgorithms.h"
+#include "cmDefinitions.h"
 #include "cmLinkedTree.h"
 #include "cmPolicies.h"
+#include "cmProperty.h"
 #include "cmPropertyDefinitionMap.h"
 #include "cmPropertyMap.h"
 
-class cmake;
+#include 
+#include 
+#include 
+#include 
+
+class cmCacheManager;
 class cmCommand;
-class cmDefinitions;
 class cmListFileBacktrace;
-class cmCacheManager;
+class cmPropertyDefinition;
 
 class cmState
 {
diff --git a/Source/cmSystemTools.h b/Source/cmSystemTools.h
index d0a28e1..3c1a9f4 100644
--- a/Source/cmSystemTools.h
+++ b/Source/cmSystemTools.h
@@ -12,10 +12,13 @@
 #ifndef cmSystemTools_h
 #define cmSystemTools_h
 
-#include "cmStandardIncludes.h"
+#include  // IWYU pragma: keep
 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 class cmSystemToolsFileTime;
 
diff --git a/Source/cmTarget.cxx b/Source/cmTarget.cxx
index 8476538..5681885 100644
--- a/Source/cmTarget.cxx
+++ b/Source/cmTarget.cxx
@@ -12,21 +12,25 @@
 #include "cmTarget.h"
 
 #include "cmAlgorithms.h"
-#include "cmComputeLinkInformation.h"
 #include "cmGeneratorExpression.h"
-#include "cmGeneratorExpressionDAGChecker.h"
+#include "cmGeneratorTarget.h"
 #include "cmGlobalGenerator.h"
 #include "cmListFileCache.h"
 #include "cmMakefile.h"
 #include "cmOutputConverter.h"
+#include "cmProperty.h"
 #include "cmSourceFile.h"
+#include "cmSourceFileLocation.h"
+#include "cmSystemTools.h"
 #include "cmake.h"
+
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include  // required for atof
+#include 
+#include 
 
 #if defined(CMake_HAVE_CXX_UNORDERED_SET)
 #include 

[cmake-developers] Appx generator for CPack?

[Ryan Saunders via cmake-developers]

Hi CMake people!
I notice that there is no CPack generator for Microsoft's .appx package format. 
I would like there to be. It seems pretty straightforward to do...basically 
just get all the files into the right directory structure (similarly to the 
archive generators, I think), and then call out to Visual Studio's MakeAppx.exe 
to create the package.
Two questions:1. Is anyone already working on this? If not, then I'll attempt 
it.2. Am I missing anything? Any "gotchas" I should worry about?
Ryan-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [CMake] Need ideas/opinions on third party library management

[Daniel Schepler]

For what it's worth, what I've done here is to create binary packages of each 
third-party library for each supported platform (i.e. .deb packages for Ubuntu, 
.rpm packages for RHEL/CentOS, Chocolatey packages for Windows).  Except for 
cases where the system already provided sufficient versions of some of the 
libraries.  At the bottom of the internal dependency chain is a base package 
which sets up the infrastructure (e.g. an /etc/profile.d file to add a shell 
function to add entries to CMAKE_PREFIX_PATH, LD_LIBRARY_PATH, etc.) and at the 
top is a set of dependency metapackages, one for each product we have to build. 
 And yes, the middle layer has a combination of large packages like Qt and 
Boost with smaller packages like Expat and SQLite.

Pluses:
- Extremely convenient for an internal developer to just follow a few 
instructions to add our internal repository, then run "apt-get install 
anchorage-exata-deps".
- Similarly convenient for customers developing custom code on top of our code 
if we provide an archive of the required packages, then they can point 
apt/yum/chocolatey to a file: URL.
- It's not too difficult to support installing multiple parallel versions of 
the development environment for different versions of the product - just have 
each one install to a different location, and then the developer selects what 
to use by running the appropriate shell function.
- Greatly simplifies the CMake files for our code, since you just use the 
standard find_package() command (possibly requiring us to write a Find*.cmake 
module).
- Flexibility of being able to easily experiment with a new or custom-compiled 
version of one of the dependencies.
- If an internal developer happens to prefer working on a platform which we 
don't officially support (e.g. Debian testing or Mint), it's generally easy to 
git clone my packaging repositories and build packages for yourself.

Minuses:
- Duplicate packaging work for each different packaging tool when adding a new 
third-party library.
- I haven't yet automated the process of building binary packages and uploading 
to our repository; so when updating any package to a new version (or adding a 
local patch) there's a lot of manual work to do.  (dupload and reprepro help a 
bit for the Ubuntu builds, and nuget has a built-in facility to upload to our 
server; but I haven't found anything similar for the RPM builds.)
- When we do a release and then need to "fork" the repository to a new 
location, it requires a rebuild of all packages at least on Linux.

Overall, most of the pluses apply to everybody, whereas the minuses are just a 
burden on me (or a future maintainer of the repository).  So overall, it's been 
a big improvement over what we used to do, which was to try to maintain binary 
builds of the third-party libraries in SVN.
--
Daniel Schepler
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Ruslan Baratov via CMake]

On 16-Aug-16 16:37, Florent Castelli wrote:
Well, I tried upstreaming the new build scripts to some projects and 
it didn’t go well.

Some of the reasons I’ve heard of:
- Windows developpers don’t use CMake, they have project files on the 
repository.

  The CMake files for Windows will never be updated.
They can coexists, it's easier then maintaining forks. If only C++ code 
changed you got new version "for free".


- I installed CMake 2.8.6 five years ago and I don’t want to update 
yet again!
  People relying on old versions is quite common and any attempt to 
raise the min
  version will be frowned upon (see the discussion in the LLVM mailing 
lists for example).
You can add `if(CMAKE_VERSION VERSION_LESS ...)` condition. It's hard to 
support such hairy configuration but anyway.



- We prefer to use autotools and don’t want to have to learn CMake.
  That’s fair. But also, no one likes to build an autotools backed 
project for Android or iOS.
Just for your info Hunter use build scheme for autotools project: 
https://github.com/ruslo/hunter/blob/b4c370e32798cc3da74c37e4156c3bfc77add379/cmake/modules/hunter_autotools_project.cmake
It can create universal iOS libraries and works for Android. There are a 
lot of efforts made by Alexandre Pretyman so this can be possible, it 
has some peculiarities. I guess he can clarify anything if you need details.


Ruslo
--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] Need ideas/opinions on third party library management

[Ruslan Baratov via CMake]

On 13-Aug-16 03:12, Elizabeth A. Fischer wrote:
I don't think CMake is the best place to do it, for a number of 
reasons.  I would not try to re-invent the wheel here.


Can you provide any details? I personally think that CMake is a natural 
and the only place where it should be done.



On 16-Aug-16 15:52, Elizabeth A. Fischer wrote:
But any approach that requires every build to be ported to CMake will 
be difficult and labor-prone to scale.  Writing a meta-build recipe is 
usually much easier.


It is difficult indeed but it's the only way to reach the goal. I have 
kind of a meta-build recipe for the Boost, it was the first non-cmake 
recipe I've added and it's almost 3 year of improvements behind but it's 
still far from what I get in CMake from the box (of course it's not 3 
years of development of just this recipe, but anyway). Just take a look 
at this code:


  add_executable(foo foo.cpp)
  add_library(boo boo.cpp)

With CMake:

   No options: you got executable and static library on host
   BUILD_SHARED_LIBS: you got shared library
   CMAKE_MACOSX_BUNDLE: you got bundle instead of executable
   CMAKE_TOOLCHAIN_FILE=android.cmake: you got library for Android
   CMAKE_TOOLCHAIN_FILE=ios.cmake: you got armv7 library for iOS
   CMAKE_TOOLCHAIN_FILE=ios.cmake + CMAKE_IOS_INSTALL_COMBINED: you got
   armv7 + arm64 + i386 + x86_64 universal library
   /* your toolchain file here */: ...
   Debug: you compile with -O0 for *nix or /Od for MSVC
   MinSizeRel: you compile with -Os for *nix or /O1
   /* your custom build type here */: ...
   Any usage requirements? Propagated AUTOMATICALLY to any project that
   use your library: compiler flags, definitions, dependent libraries, etc.
   Optional dependencies? No problems, usage requirements propagated
   too. Same code! No changes needed.
   Usage requirements change from one version to another? Again, no
   problems.

So I choose to add CMakeLists.txt almost in all cases when new package 
needed. Exceptions are big libraries with a lot of components such as Qt 
or Boost, it's unmaintainable approach, inevitable evil :(


Ruslo

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] cmake -E capabilities [v3]

[Brad King]

On 08/16/2016 02:39 PM, Tobias Hunger wrote:
> Did you make any progress with libuv? I would love to start pushing
> the server-mode patches. All the other pieces are in place already!

Great.  I haven't gotten a chance to import libuv yet.  Now that
you're ready for it I'll try to raise priority on that a bit.

-Brad

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v3.6.1-1274-gbbafe31

[Brad King]

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, next has been updated
   via  bbafe31c4f905a77622f6da7307c05dba838ac80 (commit)
   via  ea51b71a4f76597ada400d8bdea75cc9548530a3 (commit)
   via  c18dc6fbe5b68312be52353aa0a493106584ffe7 (commit)
  from  1dde35c113c24ec4d47e1a624ee68ae797e6a2c6 (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=bbafe31c4f905a77622f6da7307c05dba838ac80
commit bbafe31c4f905a77622f6da7307c05dba838ac80
Merge: 1dde35c ea51b71
Author: Brad King 
AuthorDate: Tue Aug 16 14:27:14 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 14:27:14 2016 -0400

Merge topic 'cmake-developer-reference' into next

ea51b71a QtIFW: Developer Reference installation
c18dc6fb Added CMake_BUILD_DEVELOPER_REFERENCE option


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ea51b71a4f76597ada400d8bdea75cc9548530a3
commit ea51b71a4f76597ada400d8bdea75cc9548530a3
Author: Konstantin Podsvirov 
AuthorDate: Thu Aug 4 13:02:39 2016 +0300
Commit: Konstantin Podsvirov 
CommitDate: Tue Aug 16 19:02:35 2016 +0300

QtIFW: Developer Reference installation

diff --git a/CMakeCPack.cmake b/CMakeCPack.cmake
index 34bb6bb..4d7c6fd 100644
--- a/CMakeCPack.cmake
+++ b/CMakeCPack.cmake
@@ -107,6 +107,14 @@ if(EXISTS "${CMAKE_ROOT}/Modules/CPack.cmake")
 if(SPHINX_QTHELP)
   list(APPEND _CPACK_IFW_COMPONENTS_ALL sphinx-qthelp)
 endif()
+if(CMake_BUILD_DEVELOPER_REFERENCE)
+  if(CMake_BUILD_DEVELOPER_REFERENCE_HTML)
+list(APPEND _CPACK_IFW_COMPONENTS_ALL cmake-developer-reference-html)
+  endif()
+  if(CMake_BUILD_DEVELOPER_REFERENCE_QTHELP)
+list(APPEND _CPACK_IFW_COMPONENTS_ALL cmake-developer-reference-qthelp)
+  endif()
+endif()
 set(_CPACK_IFW_COMPONENTS_CONFIGURATION "
   # Components
   set(CPACK_COMPONENTS_ALL \"${_CPACK_IFW_COMPONENTS_ALL}\")
@@ -122,7 +130,8 @@ if(EXISTS "${CMAKE_ROOT}/Modules/CPack.cmake")
   # Components scripts configuration
   foreach(_script
 CMake
-CMake.Documentation.SphinxHTML)
+CMake.Documentation.SphinxHTML
+CMake.DeveloperReference.HTML)
 configure_file("${CMake_SOURCE_DIR}/Source/QtIFW/${_script}.qs.in"
   "${CMake_BINARY_DIR}/${_script}.qs" @ONLY)
   endforeach()
@@ -136,6 +145,11 @@ if(EXISTS "${CMAKE_ROOT}/Modules/CPack.cmake")
 if(SPHINX_HTML)
   set(_CPACK_IFW_SHORTCUT_OPTIONAL 
"${_CPACK_IFW_SHORTCUT_OPTIONAL}component.addOperation(\"CreateShortcut\", 
\"@TargetDir@/doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}/html/index.html\",
 \"@StartMenuDir@/CMake Documentation.lnk\");\n")
 endif()
+if(CMake_BUILD_DEVELOPER_REFERENCE)
+  if(CMake_BUILD_DEVELOPER_REFERENCE_HTML)
+  set(_CPACK_IFW_SHORTCUT_OPTIONAL 
"${_CPACK_IFW_SHORTCUT_OPTIONAL}component.addOperation(\"CreateShortcut\", 
\"@TargetDir@/doc/cmake-${CMake_VERSION_MAJOR}.${CMake_VERSION_MINOR}/developer-reference/html/index.html\",
 \"@StartMenuDir@/CMake Developer Reference.lnk\");\n")
+  endif()
+endif()
 configure_file("${CMake_SOURCE_DIR}/Source/QtIFW/installscript.qs.in"
   "${CMake_BINARY_DIR}/installscript.qs" @ONLY
 )
diff --git a/CMakeCPackOptions.cmake.in b/CMakeCPackOptions.cmake.in
index 1d61613..d7a33bc 100644
--- a/CMakeCPackOptions.cmake.in
+++ b/CMakeCPackOptions.cmake.in
@@ -175,6 +175,29 @@ if(CPACK_GENERATOR MATCHES "IFW")
   set(CPACK_IFW_COMPONENT_SPHINX-QTHELP_NAME "SphinxQtHelp")
   set(CPACK_IFW_COMPONENT_SPHINX-QTHELP_VERSION "@_CPACK_IFW_PACKAGE_VERSION@")
 
+  # Developer Reference
+  set(CPACK_COMPONENT_GROUP_DEVELOPERREFERENCE_DISPLAY_NAME "Developer 
Reference")
+  set(CPACK_COMPONENT_GROUP_DEVELOPERREFERENCE_DESCRIPTION
+"CMake Reference in different formats (html, qch)")
+  set(CPACK_COMPONENT_GROUP_DEVELOPERREFERENCE_PARENT_GROUP CMake)
+  set(CPACK_IFW_COMPONENT_GROUP_DEVELOPERREFERENCE_PRIORITY 50)
+  set(CPACK_IFW_COMPONENT_GROUP_DEVELOPERREFERENCE_VERSION
+"@_CPACK_IFW_PACKAGE_VERSION@")
+
+  set(CPACK_COMPONENT_CMAKE-DEVELOPER-REFERENCE-HTML_DISPLAY_NAME "HTML")
+  set(CPACK_COMPONENT_CMAKE-DEVELOPER-REFERENCE-HTML_GROUP DeveloperReference)
+  set(CPACK_COMPONENT_CMAKE-DEVELOPER-REFERENCE-HTML_DISABLED TRUE)
+  set(CPACK_IFW_COMPONENT_CMAKE-DEVELOPER-REFERENCE-HTML_NAME "HTML")
+  set(CPACK_IFW_COMPONENT_CMAKE-DEVELOPER-REFERENCE-HTML_SCRIPT
+"@CMake_BINARY_DIR@/CMake.DeveloperReference.HTML.qs")
+  set(CPACK_IFW_COMPONENT_CMAKE-DEVELOPER-REFERENCE-HTML_VERSION 
"@_CPACK_IFW_PACKAGE_VERSION@")
+
+  

[Cmake-commits] CMake branch, next, updated. v3.6.1-1271-g1dde35c

[Brad King]

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, next has been updated
   via  1dde35c113c24ec4d47e1a624ee68ae797e6a2c6 (commit)
   via  7ded655f7ba82ea72a82d0555449f2df5ef38594 (commit)
  from  8bc1788a12d60261a957b98254694c4a776ce62a (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=1dde35c113c24ec4d47e1a624ee68ae797e6a2c6
commit 1dde35c113c24ec4d47e1a624ee68ae797e6a2c6
Merge: 8bc1788 7ded655
Author: Brad King 
AuthorDate: Tue Aug 16 14:20:09 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 14:20:09 2016 -0400

Merge topic 'FindCUDA-target-include-dirs' into next

7ded655f FindCUDA: Take NVCC include directories from target properties


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7ded655f7ba82ea72a82d0555449f2df5ef38594
commit 7ded655f7ba82ea72a82d0555449f2df5ef38594
Author: Peter Boettcher 
AuthorDate: Tue Aug 16 13:22:06 2016 -0400
Commit: Brad King 
CommitDate: Tue Aug 16 14:16:35 2016 -0400

FindCUDA: Take NVCC include directories from target properties

Fixes issue where include directories specified on the target are
not passed on to NVCC.  This includes both target_include_directories()
as well as include directories added by dependency chaining.

Closes: #14201

diff --git a/Modules/FindCUDA.cmake b/Modules/FindCUDA.cmake
index 78b716d..317a9cd 100644
--- a/Modules/FindCUDA.cmake
+++ b/Modules/FindCUDA.cmake
@@ -730,7 +730,7 @@ else()
 endif()
 
 # Set the user list of include dir to nothing to initialize it.
-set (CUDA_NVCC_INCLUDE_ARGS_USER "")
+set (CUDA_NVCC_INCLUDE_DIRS_USER "")
 set (CUDA_INCLUDE_DIRS ${CUDA_TOOLKIT_INCLUDE})
 
 macro(cuda_find_library_local_first_with_path_ext _var _names _doc _path_ext )
@@ -1025,7 +1025,7 @@ find_package_handle_standard_args(CUDA
 # Add include directories to pass to the nvcc command.
 macro(CUDA_INCLUDE_DIRECTORIES)
   foreach(dir ${ARGN})
-list(APPEND CUDA_NVCC_INCLUDE_ARGS_USER -I${dir})
+list(APPEND CUDA_NVCC_INCLUDE_DIRS_USER ${dir})
   endforeach()
 endmacro()
 
@@ -1249,17 +1249,15 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
   endif()
 
   # Initialize our list of includes with the user ones followed by the CUDA 
system ones.
-  set(CUDA_NVCC_INCLUDE_ARGS ${CUDA_NVCC_INCLUDE_ARGS_USER} 
"-I${CUDA_INCLUDE_DIRS}")
-  # Get the include directories for this directory and use them for our nvcc 
command.
-  # Remove duplicate entries which may be present since include_directories
-  # in CMake >= 2.8.8 does not remove them.
-  get_directory_property(CUDA_NVCC_INCLUDE_DIRECTORIES INCLUDE_DIRECTORIES)
-  list(REMOVE_DUPLICATES CUDA_NVCC_INCLUDE_DIRECTORIES)
-  if(CUDA_NVCC_INCLUDE_DIRECTORIES)
-foreach(dir ${CUDA_NVCC_INCLUDE_DIRECTORIES})
-  list(APPEND CUDA_NVCC_INCLUDE_ARGS -I${dir})
-endforeach()
-  endif()
+  set(CUDA_NVCC_INCLUDE_DIRS ${CUDA_NVCC_INCLUDE_DIRS_USER} 
"${CUDA_INCLUDE_DIRS}")
+  # Append the include directories for this target via generator expression, 
which is
+  # expanded by the FILE(GENERATE) call below.  This generator expression 
captures all
+  # include dirs set by the user, whether via directory properties or target 
properties
+  list(APPEND CUDA_NVCC_INCLUDE_DIRS 
"$")
+
+  # Do the same thing with compile definitions
+  set(CUDA_NVCC_COMPILE_DEFINITIONS 
"$")
+
 
   # Reset these variables
   set(CUDA_WRAP_OPTION_NVCC_FLAGS)
@@ -1349,14 +1347,6 @@ macro(CUDA_WRAP_SRCS cuda_target format generated_files)
 string(REGEX REPLACE "[-]+std=c\\+\\+11" "" _cuda_host_flags 
"${_cuda_host_flags}")
   endif()
 
-  # Get the list of definitions from the directory property
-  get_directory_property(CUDA_NVCC_DEFINITIONS COMPILE_DEFINITIONS)
-  if(CUDA_NVCC_DEFINITIONS)
-foreach(_definition ${CUDA_NVCC_DEFINITIONS})
-  list(APPEND nvcc_flags "-D${_definition}")
-endforeach()
-  endif()
-
   if(_cuda_build_shared_libs)
 list(APPEND nvcc_flags "-D${cuda_target}_EXPORTS")
   endif()
diff --git a/Modules/FindCUDA/run_nvcc.cmake b/Modules/FindCUDA/run_nvcc.cmake
index ff1f515..28cc1e9 100644
--- a/Modules/FindCUDA/run_nvcc.cmake
+++ b/Modules/FindCUDA/run_nvcc.cmake
@@ -73,10 +73,25 @@ set(CUDA_NVCC_EXECUTABLE "@CUDA_NVCC_EXECUTABLE@") # path
 set(CUDA_NVCC_FLAGS @CUDA_NVCC_FLAGS@ ;; @CUDA_WRAP_OPTION_NVCC_FLAGS@) # list
 @CUDA_NVCC_FLAGS_CONFIG@
 set(nvcc_flags @nvcc_flags@) # list
-set(CUDA_NVCC_INCLUDE_ARGS "@CUDA_NVCC_INCLUDE_ARGS@") # list 

Re: [cmake-developers] [PATCH v7] For Windows encode process output to internally used encoding

[Brad King]

On 08/15/2016 04:34 PM, Dāvis Mosāns wrote:
> Typically Windows applications (eg. MSVC compiler) use current console's
> codepage for output to pipes so we need to encode that to internally used
> encoding (KWSYS_ENCODING_DEFAULT_CODEPAGE).

Thanks.  Applied with minor tweaks and merged to `next` for testing:

 Windows: Encode child process output to internally-used encoding
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a818239

-Brad
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] llvm coverage format .profdata

[Brad King]

On 08/15/2016 02:24 PM, Alex Ciobanu wrote:
> Are there any plans in this direction?

Not currently, but one can look at the implementations of the currently
supported formats to add it.

Thanks,
-Brad

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] cmake -E capabilities [v3]

[Brad King]

On 08/15/2016 09:56 AM, Tobias Hunger wrote:
> here is a new update of the cmake -E capabilities patch.

Thanks.  Applied with minor revisions and an additional test:

 cmake: Add `cmake -E capabilities` mode
 https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49ad7f9a

-Brad

-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [PATCH] cmFileCommand: Download continuation support

[Brad King]

On 08/16/2016 07:11 AM, Titov Denis wrote:
> This patch introduces several options for the file(DOWNLOAD ...) command, 
> which
> would be useful in case of dealing with big files or unstable network 
> connections.

Nice, thanks.  Good start.  Here are a few minor comments.

> The added options are:

Please also update `Help/command/file.rst` to document these.

> +void crossplatform_sleep(int delay_s)

Please use cmSystemTools::Delay instead.

Thanks,
-Brad
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

[Cmake-commits] CMake branch, next, updated. v3.6.1-1269-g8bc1788

[Brad King]

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, next has been updated
   via  8bc1788a12d60261a957b98254694c4a776ce62a (commit)
   via  0a8182399db73fc85a98802faae8e534e4d22767 (commit)
  from  bf26fa0d1e1eea567b656366e0510e9018b530cd (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=8bc1788a12d60261a957b98254694c4a776ce62a
commit 8bc1788a12d60261a957b98254694c4a776ce62a
Merge: bf26fa0 0a81823
Author: Brad King 
AuthorDate: Tue Aug 16 14:08:29 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 14:08:29 2016 -0400

Merge topic 'process-output-encoding' into next

0a818239 Windows: Encode child process output to internally-used encoding


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0a8182399db73fc85a98802faae8e534e4d22767
commit 0a8182399db73fc85a98802faae8e534e4d22767
Author: Dāvis Mosāns 
AuthorDate: Mon Aug 15 23:34:21 2016 +0300
Commit: Brad King 
CommitDate: Tue Aug 16 13:59:17 2016 -0400

Windows: Encode child process output to internally-used encoding

Typically Windows applications (eg. MSVC compiler) use current console's
codepage for output to pipes so we need to encode that to our
internally-used encoding (`KWSYS_ENCODING_DEFAULT_CODEPAGE`).

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index cdc8fb1..580c3eb 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -317,6 +317,8 @@ set(SRCS
   cmOrderDirectories.h
   cmPolicies.h
   cmPolicies.cxx
+  cmProcessOutput.cxx
+  cmProcessOutput.hxx
   cmProcessTools.cxx
   cmProcessTools.h
   cmProperty.cxx
@@ -375,6 +377,9 @@ set(SRCS
   cm_utf8.c
   )
 
+SET_PROPERTY(SOURCE cmProcessOutput.cxx APPEND PROPERTY COMPILE_DEFINITIONS
+  KWSYS_ENCODING_DEFAULT_CODEPAGE=${KWSYS_ENCODING_DEFAULT_CODEPAGE})
+
 set(COMMAND_INCLUDES "#include \"cmTargetPropCommandBase.cxx\"\n")
 list(APPEND SRCS cmTargetPropCommandBase.cxx)
 set_property(SOURCE cmTargetPropCommandBase.cxx PROPERTY HEADER_FILE_ONLY ON)
diff --git a/Source/cmExecProgramCommand.cxx b/Source/cmExecProgramCommand.cxx
index 58bbc31..4391a19 100644
--- a/Source/cmExecProgramCommand.cxx
+++ b/Source/cmExecProgramCommand.cxx
@@ -11,6 +11,7 @@
 */
 #include "cmExecProgramCommand.h"
 
+#include "cmProcessOutput.hxx"
 #include "cmSystemTools.h"
 
 #include 
@@ -219,6 +220,7 @@ bool cmExecProgramCommand::RunCommand(const char* command, 
std::string& output,
   int length;
   char* data;
   int p;
+  cmProcessOutput processOutput;
   while ((p = cmsysProcess_WaitForData(cp, , , CM_NULLPTR), p)) {
 if (p == cmsysProcess_Pipe_STDOUT || p == cmsysProcess_Pipe_STDERR) {
   if (verbose) {
@@ -230,6 +232,7 @@ bool cmExecProgramCommand::RunCommand(const char* command, 
std::string& output,
 
   // All output has been read.  Wait for the process to exit.
   cmsysProcess_WaitForExit(cp, CM_NULLPTR);
+  processOutput.DecodeText(output, output);
 
   // Check the result of running the process.
   std::string msg;
diff --git a/Source/cmExecuteProcessCommand.cxx 
b/Source/cmExecuteProcessCommand.cxx
index d97b25f..1ffb163 100644
--- a/Source/cmExecuteProcessCommand.cxx
+++ b/Source/cmExecuteProcessCommand.cxx
@@ -11,6 +11,7 @@
 */
 #include "cmExecuteProcessCommand.h"
 
+#include "cmProcessOutput.hxx"
 #include "cmSystemTools.h"
 
 #include 
@@ -228,17 +229,21 @@ bool 
cmExecuteProcessCommand::InitialPass(std::vector const& args,
   int length;
   char* data;
   int p;
+  cmProcessOutput processOutput;
+  std::string strdata;
   while ((p = cmsysProcess_WaitForData(cp, , , CM_NULLPTR), p)) {
 // Put the output in the right place.
 if (p == cmsysProcess_Pipe_STDOUT && !output_quiet) {
   if (output_variable.empty()) {
-cmSystemTools::Stdout(data, length);
+processOutput.DecodeText(data, length, strdata, 1);
+cmSystemTools::Stdout(strdata.c_str(), strdata.size());
   } else {
 cmExecuteProcessCommandAppend(tempOutput, data, length);
   }
 } else if (p == cmsysProcess_Pipe_STDERR && !error_quiet) {
   if (error_variable.empty()) {
-cmSystemTools::Stderr(data, length);
+processOutput.DecodeText(data, length, strdata, 2);
+cmSystemTools::Stderr(strdata.c_str(), strdata.size());
   } else {
 cmExecuteProcessCommandAppend(tempError, data, length);
   }
@@ -247,6 +252,8 @@ bool 

[Cmake-commits] CMake branch, next, updated. v3.6.1-1267-gbf26fa0

[Brad King]

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, next has been updated
   via  bf26fa0d1e1eea567b656366e0510e9018b530cd (commit)
   via  49ad7f9af84dd46e5527e6fefaa47d8bde748bca (commit)
   via  1d408dc10f492d060b8b9546c3ed3521d7051fd8 (commit)
  from  1b6398fea8e3606984decc76dc0d38092985fbd7 (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=bf26fa0d1e1eea567b656366e0510e9018b530cd
commit bf26fa0d1e1eea567b656366e0510e9018b530cd
Merge: 1b6398f 49ad7f9
Author: Brad King 
AuthorDate: Tue Aug 16 13:50:28 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 13:50:28 2016 -0400

Merge topic 'cmake-capabilities' into next

49ad7f9a cmake: Add `cmake -E capabilities` mode
1d408dc1 cmake: Constify cmake::GetRegisteredGenerators


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=49ad7f9af84dd46e5527e6fefaa47d8bde748bca
commit 49ad7f9af84dd46e5527e6fefaa47d8bde748bca
Author: Tobias Hunger 
AuthorDate: Thu Jun 30 15:38:44 2016 +0200
Commit: Brad King 
CommitDate: Tue Aug 16 13:45:05 2016 -0400

cmake: Add `cmake -E capabilities` mode

Add `cmake -E capabilities` to report on generators, cmake version and
possibly other static capabilities of cmake.

Closes: #15462

diff --git a/Help/manual/cmake.1.rst b/Help/manual/cmake.1.rst
index 8f7c336..2ccc6be 100644
--- a/Help/manual/cmake.1.rst
+++ b/Help/manual/cmake.1.rst
@@ -180,6 +180,43 @@ CMake provides builtin command-line tools through the 
signature::
 Run ``cmake -E`` or ``cmake -E help`` for a summary of commands.
 Available commands are:
 
+``capabilities``
+  Report cmake capabilities in JSON format. The output is a JSON object
+  with the following keys:
+
+  ``version``
+A JSON object with version information. Keys are:
+
+``string``
+  The full version string as displayed by cmake ``--version``.
+``major``
+  The major version number in integer form.
+``minor``
+  The minor version number in integer form.
+``patch``
+  The patch level in integer form.
+``suffix``
+  The cmake version suffix string.
+``isDirty``
+  A bool that is set if the cmake build is from a dirty tree.
+
+  ``generators``
+A list available generators. Each generator is a JSON object with the
+following keys:
+
+``name``
+  A string containing the name of the generator.
+``toolsetSupport``
+  ``true`` if the generator supports toolsets and ``false`` otherwise.
+``platformSupport``
+  ``true`` if the generator supports platforms and ``false`` otherwise.
+``extraGenerators``
+  A list of strings with all the extra generators compatible with
+  the generator.
+
+  ``serverMode``
+``true`` if cmake supports server-mode and ``false`` otherwise.
+
 ``chdir   [...]``
   Change the current working directory and run a command.
 
diff --git a/Help/release/dev/cmake-capabilities.rst 
b/Help/release/dev/cmake-capabilities.rst
new file mode 100644
index 000..7abb973
--- /dev/null
+++ b/Help/release/dev/cmake-capabilities.rst
@@ -0,0 +1,6 @@
+cmake-capabilities
+--
+
+* :manual:`cmake(1)` gained a ``-E capabilities`` option to provide a
+  machine-readable (JSON) description of the capabilities of the
+  cmake tool (available generators, etc.).
diff --git a/Source/cmake.cxx b/Source/cmake.cxx
index a265ead..4313d83 100644
--- a/Source/cmake.cxx
+++ b/Source/cmake.cxx
@@ -23,11 +23,15 @@
 #include "cmState.h"
 #include "cmTest.h"
 #include "cmUtils.hxx"
+#include "cmVersionMacros.h"
 
 #if defined(CMAKE_BUILD_WITH_CMAKE)
 #include "cmGraphVizWriter.h"
 #include "cmVariableWatch.h"
 #include 
+
+#include "cm_jsoncpp_value.h"
+#include "cm_jsoncpp_writer.h"
 #endif
 
 #include 
@@ -110,6 +114,18 @@
 
 #include 
 
+namespace {
+
+#if defined(CMAKE_BUILD_WITH_CMAKE)
+#ifdef CMake_HAVE_CXX_UNORDERED_MAP
+typedef std::unordered_map JsonValueMapType;
+#else
+typedef cmsys::hash_map JsonValueMapType;
+#endif
+#endif
+
+} // namespace
+
 static bool cmakeCheckStampFile(const char* stampName);
 static bool cmakeCheckStampList(const char* stampName);
 
@@ -201,6 +217,68 @@ cmake::~cmake()
   delete this->FileComparison;
 }
 
+std::string cmake::ReportCapabilities() const
+{
+  std::string result;
+#if defined(CMAKE_BUILD_WITH_CMAKE)
+  Json::Value obj = Json::objectValue;
+  // Version information:
+  Json::Value version = Json::objectValue;
+  version["string"] = CMake_VERSION;
+  version["major"] = 

[Cmake-commits] CMake branch, next, updated. v3.6.1-1264-g1b6398f

[Brad King]

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, next has been updated
   via  1b6398fea8e3606984decc76dc0d38092985fbd7 (commit)
   via  e240a7c0176450e092e2398148c1e13f8940c239 (commit)
   via  074d098ffb001c6e6c03483746c7bb6e02ab4484 (commit)
   via  447b142b6a5ae8ee1669cb1a424619af808f1c17 (commit)
   via  6b07972fbdf7e8687577a430597e40e7e0b4831d (commit)
  from  cac8c6542a38c2a234e39af7a99e46e8ad5ab336 (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=1b6398fea8e3606984decc76dc0d38092985fbd7
commit 1b6398fea8e3606984decc76dc0d38092985fbd7
Merge: cac8c65 e240a7c
Author: Brad King 
AuthorDate: Tue Aug 16 13:26:32 2016 -0400
Commit: Brad King 
CommitDate: Tue Aug 16 13:26:32 2016 -0400

Merge branch 'master' into next


---

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
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.1-634-g074d098

[Brad King]

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  074d098ffb001c6e6c03483746c7bb6e02ab4484 (commit)
   via  8ba204a69602ca8744aeec4ca3d808c964715ed5 (commit)
  from  447b142b6a5ae8ee1669cb1a424619af808f1c17 (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=074d098ffb001c6e6c03483746c7bb6e02ab4484
commit 074d098ffb001c6e6c03483746c7bb6e02ab4484
Merge: 447b142 8ba204a
Author: Brad King 
AuthorDate: Tue Aug 16 13:26:19 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 13:26:19 2016 -0400

Merge topic 'FindMatlab-mingw'

8ba204a6 FindMatlab: Use pre-built libraries for MinGW if needed


---

Summary of changes:
 Modules/FindMatlab.cmake |6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.6.1-632-g447b142

[Brad King]

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  447b142b6a5ae8ee1669cb1a424619af808f1c17 (commit)
   via  2bdba83e4bbd5435ee6faf5a2eedec4f0d0dfb0a (commit)
  from  6b07972fbdf7e8687577a430597e40e7e0b4831d (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=447b142b6a5ae8ee1669cb1a424619af808f1c17
commit 447b142b6a5ae8ee1669cb1a424619af808f1c17
Merge: 6b07972 2bdba83
Author: Brad King 
AuthorDate: Tue Aug 16 13:26:15 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 13:26:15 2016 -0400

Merge topic 'issue-tracker-urls'

2bdba83e issues: update references to the CMake issue tracker


---

Summary of changes:
 Modules/CMakeDetermineCCompiler.cmake   |2 +-
 Modules/CMakeDetermineCXXCompiler.cmake |2 +-
 Modules/CMakeFindEclipseCDT4.cmake  |2 +-
 Modules/Compiler/IAR.cmake  |5 +++--
 Modules/ExternalProject.cmake   |2 +-
 Modules/FindHDF5.cmake  |4 ++--
 Source/cmExtraCodeBlocksGenerator.cxx   |4 ++--
 Source/cmExtraEclipseCDT4Generator.cxx  |4 ++--
 Source/cmExtraSublimeTextGenerator.cxx  |2 +-
 Source/cmQtAutoGeneratorInitializer.cxx |2 +-
 Tests/CPackComponents/Issue 7470.html   |4 ++--
 Tests/CTestLimitDashJ/CMakeLists.txt|2 +-
 12 files changed, 18 insertions(+), 17 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.6.1-1259-gcac8c65

[Brad King]

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, next has been updated
   via  cac8c6542a38c2a234e39af7a99e46e8ad5ab336 (commit)
   via  a8345d65f359d75efb057d22976cfb92b4d477cf (commit)
  from  7a4d3516aedece0736be4c1ad1702522a3526dd6 (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=cac8c6542a38c2a234e39af7a99e46e8ad5ab336
commit cac8c6542a38c2a234e39af7a99e46e8ad5ab336
Merge: 7a4d351 a8345d6
Author: Brad King 
AuthorDate: Tue Aug 16 13:24:37 2016 -0400
Commit: CMake Topic Stage 
CommitDate: Tue Aug 16 13:24:37 2016 -0400

Merge topic 'ExternalProject-SOURCE_SUBDIR' into next

a8345d65 ExternalProject: Add SOURCE_SUBDIR option


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a8345d65f359d75efb057d22976cfb92b4d477cf
commit a8345d65f359d75efb057d22976cfb92b4d477cf
Author: Matthew Woehlke 
AuthorDate: Mon Aug 15 14:42:22 2016 -0400
Commit: Brad King 
CommitDate: Tue Aug 16 13:18:18 2016 -0400

ExternalProject: Add SOURCE_SUBDIR option

Add a new SOURCE_SUBDIR option to ExternalProject_Add that allows
specifying the location of the CMakeLists.txt to use as the project root
relative to the SOURCE_DIR.

This is helpful for projects that have unusual layouts, or projects that
provide both a superbuild and project-only build depending on which
CMakeLists.txt is used.

Fixes: #15118

diff --git a/Modules/ExternalProject.cmake b/Modules/ExternalProject.cmake
index 2ff18fc..634ef42 100644
--- a/Modules/ExternalProject.cmake
+++ b/Modules/ExternalProject.cmake
@@ -98,6 +98,8 @@ Create custom targets to build projects in external trees
 
   ``SOURCE_DIR ``
 Source dir to be used for build
+  ``SOURCE_SUBDIR ``
+Path to source CMakeLists.txt relative to ``SOURCE_DIR``
   ``CONFIGURE_COMMAND ...``
 Build tree configuration command
   ``CMAKE_COMMAND /.../cmake``
@@ -236,6 +238,11 @@ Create custom targets to build projects in external trees
   interpreted with respect to the build directory corresponding to the
   source directory in which ``ExternalProject_Add`` is invoked.
 
+  If ``SOURCE_SUBDIR`` is set and no ``CONFIGURE_COMMAND`` is specified, the
+  configure command will run CMake using the ``CMakeLists.txt`` located in the
+  relative path specified by ``SOURCE_SUBDIR``, relative to the ``SOURCE_DIR``.
+  If no ``SOURCE_SUBDIR`` is given, ``SOURCE_DIR`` is used.
+
   If ``SOURCE_DIR`` is explicitly set to an existing directory the project
   will be built from it.  Otherwise a download step must be specified
   using one of the ``DOWNLOAD_COMMAND``, ``CVS_*``, ``SVN_*``, or ``URL``
@@ -287,8 +294,8 @@ Create custom targets to build projects in external trees
 
   The command line, comment, working directory, and byproducts of every
   standard and custom step are processed to replace tokens ,
-  , , and  with
-  corresponding property values.
+  ,  , , and 
+  with corresponding property values.
 
 Any builtin step that specifies a ``_COMMAND cmd...`` or custom
 step that specifies a ``COMMAND cmd...`` may specify additional command
@@ -1064,6 +1071,13 @@ function(_ep_set_directories name)
 endif()
 set_property(TARGET ${name} PROPERTY _EP_${VAR}_DIR "${${var}_dir}")
   endforeach()
+  get_property(source_subdir TARGET ${name} PROPERTY _EP_SOURCE_SUBDIR)
+  if(NOT source_subdir)
+set_property(TARGET ${name} PROPERTY _EP_SOURCE_SUBDIR ".")
+  elseif(IS_ABSOLUTE "${source_subdir}")
+message(FATAL_ERROR
+  "External project ${name} has non-relative SOURCE_SUBDIR!")
+  endif()
   if(build_in_source)
 get_property(source_dir TARGET ${name} PROPERTY _EP_SOURCE_DIR)
 set_property(TARGET ${name} PROPERTY _EP_BINARY_DIR "${source_dir}")
@@ -1095,7 +1109,7 @@ macro(_ep_replace_location_tags target_name)
   set(vars ${ARGN})
   foreach(var ${vars})
 if(${var})
-  foreach(dir SOURCE_DIR BINARY_DIR INSTALL_DIR TMP_DIR DOWNLOADED_FILE)
+  foreach(dir SOURCE_DIR SOURCE_SUBDIR BINARY_DIR INSTALL_DIR TMP_DIR 
DOWNLOADED_FILE)
 get_property(val TARGET ${target_name} PROPERTY _EP_${dir})
 string(REPLACE "<${dir}>" "${val}" ${var} "${${var}}")
   endforeach()
@@ -2131,7 +2145,7 @@ endfunction()
 
 # TODO: Make sure external projects use the proper compiler
 function(_ep_add_configure_command name)
-  ExternalProject_Get_Property(${name} source_dir binary_dir tmp_dir)
+  ExternalProject_Get_Property(${name} source_dir source_subdir binary_dir 
tmp_dir)
 
   # Depend on other external 

Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Ruslan Baratov via CMake]

On 16-Aug-16 17:04, Florent Castelli wrote:


On 16 Aug 2016, at 15:29, Ruslan Baratov > wrote:


On 16-Aug-16 13:52, Florent Castelli wrote:
For example, Boost is used by 5 platforms: Windows, OSX, Linux, 
Android and iOS.

Each platform has a different CPU target (or many 32/64bit, x86/ARM).
Each platform has many compilers.
Some platforms have instrumentation options (Debug / Release, ASan, 
MSan…) and really need

to be compiled properly, otherwise you’ll end up with false positives.
The matrix of builds is REALLY hard to track. Each time we update 
Boost, we had to update

a lot of things.

Not a problem for Hunter.

Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, 
LeakSan, ThreadSan, Static Analyzer,  libstdc++, libc++, MinGW, 
Visual Studio 2008-2015:

* https://travis-ci.org/ingenue/hunter/builds/140317830
* https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665

This list is not even full, I guess I can add more toolchains in 
future (GCC variations and C++ standards).


To test all matrix I need to push one commit to pkg.boost branch, to 
upload binaries to server I need to push one commit to upload.boost 
branch (upload ALL toolchains at one shot). To reuse all updates 
users just need to set new URL/SHA1 of HunterGate module: 
https://github.com/ruslo/hunter/releases


Overall, building boost takes 10s on our developers’ machines. The 
sources aren’t changed often,

so the cost is pretty low.
What kind of hardware do they have? And what libraries you mean? It 
takes about 20 seconds on my Linux machine just to unpack 80 MB of 
Boost release archive. It's even worse on Windows, it takes several 
minutes for some strange reason even on SSD + Core i7. Using binaries 
in such cases is a huge time saver because there is no need to 
compile anything and there is no a lot of junk that they put into 
release archive (if you remove docs and tests 80 MB became 15 MB).


I consider the time to download Boost isn’t part of the build.
I'm not counting that. It takes 20 seconds just to unpack archive that 
already downloaded. Anyway I'm just wondering what is possible to do 
with Boost for 10 seconds. Install header-only libraries? Build 1-2 
libraries? All of them? :)


The Boost source download is cached outside of the build directory in 
a unique folder.

So it’s effectively only done once for all platforms and then reused.
This is true for local machines and for custom build servers like your 
personal Jenkins. For Travis/AppVeyor you have to create root folder 
with 3rd parties from scratch for each build (at least for free public 
accounts).




You’ll also have symbols and the sources available for debugging 
properly, and they’re

not always available with a binary distribution.
Just to clarify: with Hunter you're creating binaries from sources, so 
everything you install with `cmake --build _builds --target install` (or 
`./b2 install` for Boost) is available.





Of course building from source is not an option for such monsters 
like Qt or OpenCV. Ready-to-use binaries is something critical for 
real life applications. There is no way to test everything on 
Travis/AppVeyor without this feature.


Well, you don’t have to use Travis or AppVeyor.
It's the most powerful and easy to setup services I know. If you know 
any better solutions please share.



Spotify isn’t at the same scale as most
projects hosted there and we have different requirements and resources.
Admittedly, Spotify doesn’t use Qt anymore, so this isn’t a problem 
for us.
It's not about Qt, it's about expandability. Use 20 of smaller libraries 
and you will have quite the same issues.




Note that by integrating everything in the same project, you also have 
proper dependencies
and you will only build what you need. You may save some time by doing 
that.

And caching is important, when done in the right way!
With Hunter you're installing only what you need too, it does respect 
options like FOO_WITH_OPENSSL or FOO_WITH_QT, it download only binaries 
for toolchain you're currently working on, etc.


Don't want to make a discussion too broad. You said that it's hard to 
manage binaries for a lot of configuration, I'm saying that it's 
possible and is very handy.


Ruslo
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Ruslan Baratov via CMake]

On 16-Aug-16 13:52, Florent Castelli wrote:

For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS.
Each platform has a different CPU target (or many 32/64bit, x86/ARM).
Each platform has many compilers.
Some platforms have instrumentation options (Debug / Release, ASan, MSan…) and 
really need
to be compiled properly, otherwise you’ll end up with false positives.
The matrix of builds is REALLY hard to track. Each time we update Boost, we had 
to update
a lot of things.

Not a problem for Hunter.

Linux, OSX, Windows, iOS 9.3, iOS 8.2, Android, GCC, Clang, ASan, 
LeakSan, ThreadSan, Static Analyzer,  libstdc++, libc++, MinGW, Visual 
Studio 2008-2015:

* https://travis-ci.org/ingenue/hunter/builds/140317830
* https://ci.appveyor.com/project/ingenue/hunter/build/1.0.665

This list is not even full, I guess I can add more toolchains in future 
(GCC variations and C++ standards).


To test all matrix I need to push one commit to pkg.boost branch, to 
upload binaries to server I need to push one commit to upload.boost 
branch (upload ALL toolchains at one shot). To reuse all updates users 
just need to set new URL/SHA1 of HunterGate module: 
https://github.com/ruslo/hunter/releases



Overall, building boost takes 10s on our developers’ machines. The sources 
aren’t changed often,
so the cost is pretty low.
What kind of hardware do they have? And what libraries you mean? It 
takes about 20 seconds on my Linux machine just to unpack 80 MB of Boost 
release archive. It's even worse on Windows, it takes several minutes 
for some strange reason even on SSD + Core i7. Using binaries in such 
cases is a huge time saver because there is no need to compile anything 
and there is no a lot of junk that they put into release archive (if you 
remove docs and tests 80 MB became 15 MB).


Of course building from source is not an option for such monsters like 
Qt or OpenCV. Ready-to-use binaries is something critical for real life 
applications. There is no way to test everything on Travis/AppVeyor 
without this feature.


Ruslo
--

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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] Need ideas/opinions on third party library management

[Florent Castelli]

We have many smaller libraries and a few big ones like Boost.
It certainly takes a bit of time to setup, but it will save you a lot of time 
later.
It will keep your build scripts clean too as the user won’t have to know about
its dependencies setup. Just use “target_link_libraries” on the modern target
that was created and it will work.

Most of the 3rd party dependencies don’t work that way and they're quite painful
to use correctly. As in, if you miss to add the “add_definitions” they told you 
to use,
it will build, but source files might be used with a different preprocessor 
define and
you end up with two different implementations of the same class in the same 
binary.
It will crash in very mysterious ways. 

The most important point is *correctness*. If you experiment with tooling like
the Clang sanitizers, you’ll know that you can’t mix libraries that haven’t been
instrumented with instrumented code.
Best case the libraries are self-contained and will work all of the time.
Worst case, the libraries are mostly self-contained and will *not* work 
sometimes!

As an example, the Boost Unit Test Framework usually worked fine for us.
But sometimes, we had ASan triggering an issue in the constructor of the string
object for the test name. Our binary was built with ASan and Boost without.
When we built it from source, all the false positives went away.

I know that not a lot of people use them or have heard of them, but they are
a super important tool that will find TONS of real issues in your code the first
time you use them and we cannot do without.
Some people might rely on Valgrind Memcheck instead, but hey, this is 2016
and we like our tests to run fast(er)!


/Florent

> On 16 Aug 2016, at 14:41, Benjamin Ballet  wrote:
> 
> Very interesting discussion, we have the same issues here.
> 
> Florent Castelli, how many third parties libraries do you use ? I think a 
> super build can be a very good solution but I'm wondering how much third 
> party code you have to build. Here we use OpenCV, with, boost, and poco, and 
> other things... So it may be too long.
> 
> I was personnaly considering having an hybrid solution : include small 
> libraries (like jsoncpp) and pre-build the other for each platforms.
> 
> 
> 2016-08-16 12:52 GMT+02:00 Florent Castelli  >:
> At Spotify, we use CMake a lot for our large C++ library shared by all the 
> clients.
> After trying to build libraries for each platform and variant, we basically 
> gave up and we now
> use a super-build approach.
> 
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and 
> iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…) 
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost, we 
> had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build it 
> and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the flags 
> in your CMake files
> instead, which is still not good enough.
> 
> In the end, I looked at how Boost is actually built. And for most libraries, 
> it’s plain simple.
> A static library with a few files, some define, sometimes a platform specific 
> source file.
> What if instead of having an external build tool, I built it from CMake 
> instead?
> It would propagate all the build flags, target, instrumentation and compiler 
> information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary 
> distribution with the source
> distribution and it’s much easier. When people build our library for a 
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and patched 
> it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle 
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was 
> again effortless.
> 
> Overall, building boost takes 10s on our developers’ machines. The sources 
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but that’s 
> quite rare.
> 
> We try now to use the same approach for other libraries when we add them. 
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still 
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern 
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier 

Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Elizabeth A. Fischer]

CMake builds for existing libraries are certainly an interesting and useful
thing, and deserve to be posted in a GitHub repo somewhere.  They should
also serve as the basis of a campaign to get the library authors to
incorporate the CMake build directly in their repos.

But any approach that requires every build to be ported to CMake will be
difficult and labor-prone to scale.  Writing a meta-build recipe is usually
much easier.

Spack handles the combinatorial dependencies you mention in a
sophisticated, graceful way that most meta-builders do not.  Its only
problem is it does not (yet) run on Windows.  There's no fundamental reason
why not; we just need someone to get involved and start trying it on
Windows.

-- Elizabeth


On Tue, Aug 16, 2016 at 6:52 AM, Florent Castelli <
florent.caste...@gmail.com> wrote:

> At Spotify, we use CMake a lot for our large C++ library shared by all the
> clients.
> After trying to build libraries for each platform and variant, we
> basically gave up and we now
> use a super-build approach.
>
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android
> and iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…)
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost,
> we had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build
> it and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the
> flags in your CMake files
> instead, which is still not good enough.
>
> In the end, I looked at how Boost is actually built. And for most
> libraries, it’s plain simple.
> A static library with a few files, some define, sometimes a platform
> specific source file.
> What if instead of having an external build tool, I built it from CMake
> instead?
> It would propagate all the build flags, target, instrumentation and
> compiler information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary
> distribution with the source
> distribution and it’s much easier. When people build our library for a
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and
> patched it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was
> again effortless.
>
> Overall, building boost takes 10s on our developers’ machines. The sources
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but
> that’s quite rare.
>
> We try now to use the same approach for other libraries when we add them.
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier to build a library for another platform that
> wasn’t targeted by the original
> project.
>
> If people are interested, I could share the CMakeLists.txt file we use for
> Boost. It doesn’t build all
> the libraries (some are hard like Context) and uses some internal macros,
> but it should be plain
> simple to tweak for your use.
>
> /Florent
>
> > On 12 Aug 2016, at 21:59, Robert Dailey 
> wrote:
> >
> > Hello,
> >
> > There is an internal C++ product at the company I work for which I
> > have written a series of CMake scripts for. This project actually has
> > dependencies on several open source libraries, such as boost,
> > freetype, openssl, etc.
> >
> > Right now what we do is build each of these third party libraries *by
> > hand*, once for every platform we support (Windows, Linux x86, Android
> > NDK). Then we stuff the includes (headers) and libraries
> > (static/shared) in a submodule and the primary code base's CMake
> > scripts pull them in as interface targets.
> >
> > This works well and is light-weight but is a pain when upgrading or
> > changing libraries. It's a pain because if I want to upgrade boost, I
> > have to build it up to 6 times (once for each platform and once for
> > each configuration).
> >
> > I've been thinking of a different approach for a while. I've done some
> > toying around with the "Super Build" concept, where I have a separate
> > CMake project that does nothing but use the ExternalProject module to
> > build libraries in real time along with our project. So the order of
> > operations would be 

Re: [cmake-developers] Need ideas/opinions on third party library management

[Elizabeth A. Fischer]

CMake builds for existing libraries are certainly an interesting and useful
thing, and deserve to be posted in a GitHub repo somewhere.  They should
also serve as the basis of a campaign to get the library authors to
incorporate the CMake build directly in their repos.

But any approach that requires every build to be ported to CMake will be
difficult and labor-prone to scale.  Writing a meta-build recipe is usually
much easier.

Spack handles the combinatorial dependencies you mention in a
sophisticated, graceful way that most meta-builders do not.  Its only
problem is it does not (yet) run on Windows.  There's no fundamental reason
why not; we just need someone to get involved and start trying it on
Windows.

-- Elizabeth


On Tue, Aug 16, 2016 at 6:52 AM, Florent Castelli <
florent.caste...@gmail.com> wrote:

> At Spotify, we use CMake a lot for our large C++ library shared by all the
> clients.
> After trying to build libraries for each platform and variant, we
> basically gave up and we now
> use a super-build approach.
>
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android
> and iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…)
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost,
> we had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build
> it and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the
> flags in your CMake files
> instead, which is still not good enough.
>
> In the end, I looked at how Boost is actually built. And for most
> libraries, it’s plain simple.
> A static library with a few files, some define, sometimes a platform
> specific source file.
> What if instead of having an external build tool, I built it from CMake
> instead?
> It would propagate all the build flags, target, instrumentation and
> compiler information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary
> distribution with the source
> distribution and it’s much easier. When people build our library for a
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and
> patched it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was
> again effortless.
>
> Overall, building boost takes 10s on our developers’ machines. The sources
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but
> that’s quite rare.
>
> We try now to use the same approach for other libraries when we add them.
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier to build a library for another platform that
> wasn’t targeted by the original
> project.
>
> If people are interested, I could share the CMakeLists.txt file we use for
> Boost. It doesn’t build all
> the libraries (some are hard like Context) and uses some internal macros,
> but it should be plain
> simple to tweak for your use.
>
> /Florent
>
> > On 12 Aug 2016, at 21:59, Robert Dailey 
> wrote:
> >
> > Hello,
> >
> > There is an internal C++ product at the company I work for which I
> > have written a series of CMake scripts for. This project actually has
> > dependencies on several open source libraries, such as boost,
> > freetype, openssl, etc.
> >
> > Right now what we do is build each of these third party libraries *by
> > hand*, once for every platform we support (Windows, Linux x86, Android
> > NDK). Then we stuff the includes (headers) and libraries
> > (static/shared) in a submodule and the primary code base's CMake
> > scripts pull them in as interface targets.
> >
> > This works well and is light-weight but is a pain when upgrading or
> > changing libraries. It's a pain because if I want to upgrade boost, I
> > have to build it up to 6 times (once for each platform and once for
> > each configuration).
> >
> > I've been thinking of a different approach for a while. I've done some
> > toying around with the "Super Build" concept, where I have a separate
> > CMake project that does nothing but use the ExternalProject module to
> > build libraries in real time along with our project. So the order of
> > operations would be 

Re: [CMake] [cmake-developers] Need ideas/opinions on third party library management

[Benjamin Ballet via CMake]

Very interesting discussion, we have the same issues here.

Florent Castelli, how many third parties libraries do you use ? I think a
super build can be a very good solution but I'm wondering how much third
party code you have to build. Here we use OpenCV, with, boost, and poco,
and other things... So it may be too long.

I was personnaly considering having an hybrid solution : include small
libraries (like jsoncpp) and pre-build the other for each platforms.


2016-08-16 12:52 GMT+02:00 Florent Castelli :

> At Spotify, we use CMake a lot for our large C++ library shared by all the
> clients.
> After trying to build libraries for each platform and variant, we
> basically gave up and we now
> use a super-build approach.
>
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android
> and iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…)
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost,
> we had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build
> it and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the
> flags in your CMake files
> instead, which is still not good enough.
>
> In the end, I looked at how Boost is actually built. And for most
> libraries, it’s plain simple.
> A static library with a few files, some define, sometimes a platform
> specific source file.
> What if instead of having an external build tool, I built it from CMake
> instead?
> It would propagate all the build flags, target, instrumentation and
> compiler information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary
> distribution with the source
> distribution and it’s much easier. When people build our library for a
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and
> patched it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was
> again effortless.
>
> Overall, building boost takes 10s on our developers’ machines. The sources
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but
> that’s quite rare.
>
> We try now to use the same approach for other libraries when we add them.
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier to build a library for another platform that
> wasn’t targeted by the original
> project.
>
> If people are interested, I could share the CMakeLists.txt file we use for
> Boost. It doesn’t build all
> the libraries (some are hard like Context) and uses some internal macros,
> but it should be plain
> simple to tweak for your use.
>
> /Florent
>
> > On 12 Aug 2016, at 21:59, Robert Dailey 
> wrote:
> >
> > Hello,
> >
> > There is an internal C++ product at the company I work for which I
> > have written a series of CMake scripts for. This project actually has
> > dependencies on several open source libraries, such as boost,
> > freetype, openssl, etc.
> >
> > Right now what we do is build each of these third party libraries *by
> > hand*, once for every platform we support (Windows, Linux x86, Android
> > NDK). Then we stuff the includes (headers) and libraries
> > (static/shared) in a submodule and the primary code base's CMake
> > scripts pull them in as interface targets.
> >
> > This works well and is light-weight but is a pain when upgrading or
> > changing libraries. It's a pain because if I want to upgrade boost, I
> > have to build it up to 6 times (once for each platform and once for
> > each configuration).
> >
> > I've been thinking of a different approach for a while. I've done some
> > toying around with the "Super Build" concept, where I have a separate
> > CMake project that does nothing but use the ExternalProject module to
> > build libraries in real time along with our project. So the order of
> > operations would be as follows (for our automated build server):
> >
> > 1. Clone our "Third Party" repository
> > 2. Use CMake to generate & build the "Super Build" project (this
> > builds boost, openssl, freetype, etc for the current platform).
> > 3. Clone the main code base's repository
> > 4. Use 

Re: [cmake-developers] Need ideas/opinions on third party library management

[Benjamin Ballet via cmake-developers]

Very interesting discussion, we have the same issues here.

Florent Castelli, how many third parties libraries do you use ? I think a
super build can be a very good solution but I'm wondering how much third
party code you have to build. Here we use OpenCV, with, boost, and poco,
and other things... So it may be too long.

I was personnaly considering having an hybrid solution : include small
libraries (like jsoncpp) and pre-build the other for each platforms.


2016-08-16 12:52 GMT+02:00 Florent Castelli :

> At Spotify, we use CMake a lot for our large C++ library shared by all the
> clients.
> After trying to build libraries for each platform and variant, we
> basically gave up and we now
> use a super-build approach.
>
> For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android
> and iOS.
> Each platform has a different CPU target (or many 32/64bit, x86/ARM).
> Each platform has many compilers.
> Some platforms have instrumentation options (Debug / Release, ASan, MSan…)
> and really need
> to be compiled properly, otherwise you’ll end up with false positives.
> The matrix of builds is REALLY hard to track. Each time we update Boost,
> we had to update
> a lot of things.
> I tried using ExternalProject and use b2 (build tool from Boost) to build
> it and instead of having
> lots of build jobs with a mirror of the flags, you end up mirroring the
> flags in your CMake files
> instead, which is still not good enough.
>
> In the end, I looked at how Boost is actually built. And for most
> libraries, it’s plain simple.
> A static library with a few files, some define, sometimes a platform
> specific source file.
> What if instead of having an external build tool, I built it from CMake
> instead?
> It would propagate all the build flags, target, instrumentation and
> compiler information from the main
> build to it and just work.
> I tried it and it worked in no time! We replaced our Boost 1.59 binary
> distribution with the source
> distribution and it’s much easier. When people build our library for a
> different target, they don’t have
> to download new binaries, they just reuse the same sources.
> Later on, we found a bug in Boost 1.59 (fixed in later versions) and
> patched it. We updated our source
> bundle and everything was smooth.
> Much later on, we wanted to use 1.61. We just updated the source bundle
> again, the list of source
> files or compilation flags for the libraries we use didn’t change. It was
> again effortless.
>
> Overall, building boost takes 10s on our developers’ machines. The sources
> aren’t changed often,
> so the cost is pretty low. It needs attention when we upgrade it, but
> that’s quite rare.
>
> We try now to use the same approach for other libraries when we add them.
> Some of them are
> already using CMake and it’s somewhat easier, but since most people still
> target version 2.8 (or 2.6...),
> we find it better to rewrite the build scripts ourselves and use modern
> features (as in, everything is
> a target that propagates requirements, we don’t propagate variables).
> It makes it also much easier to build a library for another platform that
> wasn’t targeted by the original
> project.
>
> If people are interested, I could share the CMakeLists.txt file we use for
> Boost. It doesn’t build all
> the libraries (some are hard like Context) and uses some internal macros,
> but it should be plain
> simple to tweak for your use.
>
> /Florent
>
> > On 12 Aug 2016, at 21:59, Robert Dailey 
> wrote:
> >
> > Hello,
> >
> > There is an internal C++ product at the company I work for which I
> > have written a series of CMake scripts for. This project actually has
> > dependencies on several open source libraries, such as boost,
> > freetype, openssl, etc.
> >
> > Right now what we do is build each of these third party libraries *by
> > hand*, once for every platform we support (Windows, Linux x86, Android
> > NDK). Then we stuff the includes (headers) and libraries
> > (static/shared) in a submodule and the primary code base's CMake
> > scripts pull them in as interface targets.
> >
> > This works well and is light-weight but is a pain when upgrading or
> > changing libraries. It's a pain because if I want to upgrade boost, I
> > have to build it up to 6 times (once for each platform and once for
> > each configuration).
> >
> > I've been thinking of a different approach for a while. I've done some
> > toying around with the "Super Build" concept, where I have a separate
> > CMake project that does nothing but use the ExternalProject module to
> > build libraries in real time along with our project. So the order of
> > operations would be as follows (for our automated build server):
> >
> > 1. Clone our "Third Party" repository
> > 2. Use CMake to generate & build the "Super Build" project (this
> > builds boost, openssl, freetype, etc for the current platform).
> > 3. Clone the main code base's repository
> > 4. Use 

[cmake-developers] [PATCH] cmFileCommand: Download continuation support

[Titov Denis]

This patch introduces several options for the file(DOWNLOAD ...) command, which
would be useful in case of dealing with big files or unstable network
connections.

The added options are:

RETRY_COUNT  -- sets maximal amount of download restarts, default value: 1

RETRY_DELAY  -- sets delay before restarting download (in seconds),
default value: 0.0

RETRY_MAX_TIME  -- sets maximal time spent in downloading file
(in seconds), default value: infinity

RETRY_CONTINUE -- if set, makes cmake try to continue downloading of the
existing chunk, instead of discarding it and starting all over. This option is
not set by default

Notes:

The RETRY_CONTINUE option requires server-side support of http partial get
(content-range header).

Unfortunately, I haven't been able to properly test the RETRY_CONTINUE option,
as I didn't have access to the appropriate server. Any help in this area is
encouraged.
---
 Source/cmFileCommand.cxx | 287 +--
 1 file changed, 204 insertions(+), 83 deletions(-)

diff --git a/Source/cmFileCommand.cxx b/Source/cmFileCommand.cxx
index 835b118..aa7782e 100644
--- a/Source/cmFileCommand.cxx
+++ b/Source/cmFileCommand.cxx
@@ -34,6 +34,16 @@
 // include sys/stat.h after sys/types.h
 #include 
 
+#include 
+#include 
+
+// For crossplatform_sleep().
+#if defined(_WIN32) && !defined(__CYGWIN__)
+#include 
+#else
+#include 
+#endif
+
 #include 
 #include 
 #include 
@@ -68,6 +78,15 @@ static mode_t mode_setuid = S_ISUID;
 static mode_t mode_setgid = S_ISGID;
 #endif
 
+void crossplatform_sleep(int delay_s)
+{
+#if defined(_WIN32) && !defined(__CYGWIN__)
+  Sleep(delay_s);
+#else
+  sleep(delay_s * 1000);
+#endif
+}
+
 #if defined(_WIN32) && defined(CMAKE_ENCODING_UTF8)
 // libcurl doesn't support file:// urls for unicode filenames on Windows.
 // Convert string from UTF-8 to ACP if this is a file:// URL.
@@ -2481,6 +2500,11 @@ bool 
cmFileCommand::HandleDownloadCommand(std::vector const& args)
   std::string hashMatchMSG;
   CM_AUTO_PTR hash;
   bool showProgress = false;
+  int retryMaxCount = 1;
+  double retryDelayS = 0.0;
+  double retryMaxTimeS = DBL_MAX;
+  bool retryContinue = false;
+  cmsys::ofstream fout;
 
   while (i != args.end()) {
 if (*i == "TIMEOUT") {
@@ -2564,7 +2588,34 @@ bool 
cmFileCommand::HandleDownloadCommand(std::vector const& args)
 return false;
   }
   hashMatchMSG = algo + " hash";
+} else if (*i == "RETRY_COUNT") {
+  ++i;
+  if (i != args.end()) {
+retryMaxCount = atoi(i->c_str());
+  } else {
+this->SetError("DOWNLOAD missing count for RETRY_COUNT");
+return false;
+  }
+} else if (*i == "RETRY_DELAY") {
+  ++i;
+  if (i != args.end()) {
+retryDelayS = atof(i->c_str());
+  } else {
+this->SetError("DOWNLOAD missing time for RETRY_DELAY");
+return false;
+  }
+} else if (*i == "RETRY_MAX_TIME") {
+  ++i;
+  if (i != args.end()) {
+retryMaxTimeS = atof(i->c_str());
+  } else {
+this->SetError("DOWNLOAD missing time for RETRY_MAX_TIME");
+return false;
+  }
+} else if (*i == "RETRY_CONTINUE") {
+  retryContinue = true;
 }
+
 ++i;
   }
   // If file exists already, and caller specified an expected md5 or sha,
@@ -2599,110 +2650,171 @@ bool 
cmFileCommand::HandleDownloadCommand(std::vector const& args)
 return false;
   }
 
-  cmsys::ofstream fout(file.c_str(), std::ios::binary);
-  if (!fout) {
-this->SetError("DOWNLOAD cannot open file for write.");
-return false;
-  }
-
 #if defined(_WIN32) && defined(CMAKE_ENCODING_UTF8)
   url = fix_file_url_windows(url);
 #endif
 
+  cmFileCommandVectorOfChar chunkDebug;
+
   ::CURL* curl;
   ::curl_global_init(CURL_GLOBAL_DEFAULT);
-  curl = ::curl_easy_init();
-  if (!curl) {
-this->SetError("DOWNLOAD error initializing curl.");
-return false;
-  }
 
-  cURLEasyGuard g_curl(curl);
-  ::CURLcode res = ::curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
-  check_curl_result(res, "DOWNLOAD cannot set url: ");
+  ::CURLcode res;
+  int tries = 0;
+  double elapsed = 0.0;
+  time_t start, end;
+  while (tries < retryMaxCount && elapsed <= retryMaxTimeS) {
+++tries;
+time();
+
+curl = ::curl_easy_init();
+if (!curl) {
+  this->SetError("DOWNLOAD error initializing curl.");
+  ::curl_global_cleanup();
+  return false;
+}
 
-  // enable HTTP ERROR parsing
-  res = ::curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);
-  check_curl_result(res, "DOWNLOAD cannot set http failure option: ");
+if (cmSystemTools::FileExists(file.c_str())) { // Something was downloaded.
+  // Check hash.
+  if (hash.get()) {
+std::string actualHash = hash->HashFile(file);
+if (actualHash == expectedHash) { // File is complete, exit.
+  ::curl_easy_cleanup(curl);
+  ::curl_global_cleanup();
+  return true;
+}
+  }
 
-  res = 

Re: [cmake-developers] Need ideas/opinions on third party library management

[Florent Castelli]

At Spotify, we use CMake a lot for our large C++ library shared by all the 
clients.
After trying to build libraries for each platform and variant, we basically 
gave up and we now
use a super-build approach.

For example, Boost is used by 5 platforms: Windows, OSX, Linux, Android and iOS.
Each platform has a different CPU target (or many 32/64bit, x86/ARM).
Each platform has many compilers.
Some platforms have instrumentation options (Debug / Release, ASan, MSan…) and 
really need
to be compiled properly, otherwise you’ll end up with false positives.
The matrix of builds is REALLY hard to track. Each time we update Boost, we had 
to update
a lot of things.
I tried using ExternalProject and use b2 (build tool from Boost) to build it 
and instead of having
lots of build jobs with a mirror of the flags, you end up mirroring the flags 
in your CMake files
instead, which is still not good enough.

In the end, I looked at how Boost is actually built. And for most libraries, 
it’s plain simple.
A static library with a few files, some define, sometimes a platform specific 
source file.
What if instead of having an external build tool, I built it from CMake instead?
It would propagate all the build flags, target, instrumentation and compiler 
information from the main
build to it and just work.
I tried it and it worked in no time! We replaced our Boost 1.59 binary 
distribution with the source
distribution and it’s much easier. When people build our library for a 
different target, they don’t have
to download new binaries, they just reuse the same sources.
Later on, we found a bug in Boost 1.59 (fixed in later versions) and patched 
it. We updated our source
bundle and everything was smooth.
Much later on, we wanted to use 1.61. We just updated the source bundle again, 
the list of source
files or compilation flags for the libraries we use didn’t change. It was again 
effortless.

Overall, building boost takes 10s on our developers’ machines. The sources 
aren’t changed often,
so the cost is pretty low. It needs attention when we upgrade it, but that’s 
quite rare.

We try now to use the same approach for other libraries when we add them. Some 
of them are
already using CMake and it’s somewhat easier, but since most people still 
target version 2.8 (or 2.6...),
we find it better to rewrite the build scripts ourselves and use modern 
features (as in, everything is
a target that propagates requirements, we don’t propagate variables).
It makes it also much easier to build a library for another platform that 
wasn’t targeted by the original
project.

If people are interested, I could share the CMakeLists.txt file we use for 
Boost. It doesn’t build all
the libraries (some are hard like Context) and uses some internal macros, but 
it should be plain
simple to tweak for your use.

/Florent

> On 12 Aug 2016, at 21:59, Robert Dailey  wrote:
> 
> Hello,
> 
> There is an internal C++ product at the company I work for which I
> have written a series of CMake scripts for. This project actually has
> dependencies on several open source libraries, such as boost,
> freetype, openssl, etc.
> 
> Right now what we do is build each of these third party libraries *by
> hand*, once for every platform we support (Windows, Linux x86, Android
> NDK). Then we stuff the includes (headers) and libraries
> (static/shared) in a submodule and the primary code base's CMake
> scripts pull them in as interface targets.
> 
> This works well and is light-weight but is a pain when upgrading or
> changing libraries. It's a pain because if I want to upgrade boost, I
> have to build it up to 6 times (once for each platform and once for
> each configuration).
> 
> I've been thinking of a different approach for a while. I've done some
> toying around with the "Super Build" concept, where I have a separate
> CMake project that does nothing but use the ExternalProject module to
> build libraries in real time along with our project. So the order of
> operations would be as follows (for our automated build server):
> 
> 1. Clone our "Third Party" repository
> 2. Use CMake to generate & build the "Super Build" project (this
> builds boost, openssl, freetype, etc for the current platform).
> 3. Clone the main code base's repository
> 4. Use CMake to generate & build, using find_package() to refer to
> interface targets exported by those third party libraries built in
> step 2
> 
> Obviously this will make builds take significantly longer, because
> we're constantly rebuilding the same third party libraries over and
> over again. However, it virtually eliminates the maintenance burden
> for third party libraries because they are built inherently with
> everything else.
> 
> Note that I can't refer to pre-built libraries in our build
> environments because we need very specific control over the versions
> of our libraries as well as the toolchains that were used to build
> them. Also we may specifically build our libraries a certain 

Re: [cmake-developers] [Patch 5/5] Improved WIX support

[Nils Gladitz]

On 08/16/2016 11:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:


There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I
think such an interface change would be fine.


Ok I'll do this. Should solve all issues and doubts hopefully.


Great. Thanks.



  Adding FeatureRef to #PRODUCT does not work. I get the following message:

features.wixobj : error LGHT0095 : Multiple primary references were found for 
Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'


Did you try with IgnoreParent="yes" on your FeatureRef element?
It makes sense that there can only be one root-Feature.

Nils
--

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:
http://public.kitware.com/mailman/listinfo/cmake-developers

Re: [cmake-developers] [Patch 5/5] Improved WIX support

[Stuermer, Michael SP/HZA-ZSEP]

> -Original Message-
> From: Nils Gladitz [mailto:nilsglad...@gmail.com]
> Sent: Tuesday, August 16, 2016 10:54 AM
> To: Stuermer, Michael SP/HZA-ZSEP; CMake Developers
> Subject: Re: [cmake-developers] [Patch 5/5] Improved WIX support
> 
> On 08/16/2016 10:15 AM, Stuermer, Michael SP/HZA-ZSEP wrote:
> 
> >
> > After having  look at the code for some minutes I remember why patching
> the ref instead oft he feature was my way to go:
> >
> > The feature is written to file in
> cmWIXFeaturesSourceWriter::EmitFeatureForComponent(), where I do not
> have any patch information available. This means I'd have to change the
> signature of both EmitFeatureForComponent and
> EmitFeatureForComponentGroup and pass a reference to the patch instance
> along. Multiple occurrence of IDs can happen, but the patch will only be
> applied once because applied fragments are erased immediately after
> writing them to the stream.
> >
> > So after all for me this was a consideration of a 1-line change vs. changing
> class interfaces an passing object instances to where it might not be
> desirable.
> 
> There is precedence in cmWIXFilesSourceWriter::EmitComponentFile() so I
> think such an interface change would be fine.
> 

Ok I'll do this. Should solve all issues and doubts hopefully.

> >
> > I agree the commit message of the patch is not accurate enough and if
> there is way to add custom WIX-components to features without changing
> the cpack source I'd be happy to do so. But so far I tried several approaches
> and neither worked (see below).
> >
> >> This would not be any more convenient but would certainly match
> >> expectations and be less ill defined.
> >> e.g. when I specify a patch for a Feature I expect that the Feature
> >> with the given ID gets patched.
> >>
> >> Arguments against patching a FeatureRef instead are:
> >> - There can be n FeatureRef elements for any Feature element in which
> >> case it would not be obvious if the patch should be applied to one
> >> (which?) or all of these
> > The way the patch was implemented only the featurerefs in the generated
> features.wxs file would be patched and there should not be any double
> occurences of a feature ref.
> >
> >> - While similar FeatureRef and Feature don't take the same Child
> >> elements
> > Right, and if both Feature and FeatureRef would be patchable we would be
> in trouble. For the lazy one: this is not the case at the moment so we would
> not need to worry about it (but it's very nice). For the correct one: We could
... meant NOT very nice, of course ...
> introduce another attribute to CPackWixFragment called "Type" where type
> of the XML node to be patched could be stored. But this would introduce
> additional complexity to the cmWIXPatch class...
> 
> There is no use case to be able to patch both FeatureRef and Feature
> elements when Feature elements can be patched directly.
> 
Right.
> >
> >> - You can already define your own FeatureRef elements (referencing
> >> any of the pre-existing Feature elements if wanted) without having to
> >> use the patch mechanism
> >>
> > I tried this like this (in a separate additional .wxs source file added with
> CPACK_WIX_EXTRA_SOURCES):
> >
> > http://schemas.microsoft.com/wix/2006/wi;>
> >
> >   Directory="INSTALL_ROOT">
> >
> >  
> >
> >  
> >   IgnoreParent="yes">
> >
> >  
> >
> > 
> >
> > Did not work, the registry value was not set. Using the proposed approach
> it worked. Do I have to reference it somehow different?
> 
> The linker only includes object files which provide a symbol that is required
> by an object already included.
> Your source file has a single symbol for the Component "SetRegistryValues"
> but that symbol (I assume) is not required by any of the other objects which
> the linker includes.
> 
> You could e.g. add the FeatureRef to a custom WIX.template.in (which has
> the main entry point and is therefor always included), or supply a patch for
> the Product element (#PRODUCT), or create any kind of valid reference to
> your custom source file (if any reference is resolved through your custom
> source the entire object gets included).
> 

 Adding FeatureRef to #PRODUCT does not work. I get the following message:

features.wixobj : error LGHT0095 : Multiple primary references were found for 
Feature '@feature@' in Feature 'ProductFeature' and Product '{@guid@}'

> Nils
> .

Michael

-- 

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 

Re: [CMake] Private dependencies of static libraries exported as targets

[Nicholas Braden]

Yes, the behavior is documented in several places, the most prominent
being here:
https://cmake.org/cmake/help/latest/manual/cmake-buildsystem.7.html#transitive-usage-requirements


On Mon, Aug 15, 2016 at 9:22 PM, Ivan Shapovalov  wrote:
> On 2016-08-15 at 21:46 -0400, Guillaume Dumont wrote:
>> As far as I know the PRIVATE
>> keyword
>> should have no effect on transitive linking when foo is static and we
>> call:
>>
>> target_link_libraries(foo PRIVATE bar)
>>
>> Hope this helps.
>
> Wow. I did not know that. Should've tested on sample project.
> It does not solve include path bloat though, but that's a minor issue.
>
> One question remains... is this behavior documented somewhere?
>
> Anyway, huge thanks,
> --
> Ivan Shapovalov / intelfx /
> --
>
> 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:
> http://public.kitware.com/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:
http://public.kitware.com/mailman/listinfo/cmake

Re: [cmake-developers] [CMake] Need ideas/opinions on third party library management

[Charles Huet]

Hi,

I was looking at tools that can do this kind of things myself (however I
was more looking at pre-built binaries redistribution than at a
super-build, since our build time is already quite long).

Does Conan (https://conan.io/) not fit your bill as well ?

Best

Le dim. 14 août 2016 à 02:33, Ian Henriksen <
insertinterestingnameh...@gmail.com> a écrit :

> On Sat, Aug 13, 2016 at 6:43 PM Elizabeth A. Fischer <
> elizabeth.fisc...@columbia.edu> wrote:
>
>> I would look into Anaconda, which does work for Windows.  Its version
>> management is not as well developed as Spack, but it's more cross-platform.
>>
>> Auto-builders are just coming into their own, it's a brave new world.  I
>> expect things to be more complete in a few years.
>>
>> -- Elizabeth
>>
>>
> Yes, Anaconda comes with a package manager (conda) that is designed to
> manage binary dependencies. You can get a minimal Python install with just
> the
> package manager by installing miniconda. The package management system is
> built in Python, but it can manage C and C++ libraries as well. The
> support for
> ARM isn't thoroughly built out, so you'll be building all the packages
> there for
> yourself. The support for Windwos, OS X and Linux is pretty well
> developed. You
> can look at https://repo.continuum.io/pkgs/ to see the packages available
> by
> default. There is also support for people uploading their own "channels"
> for
> packages on anaconda.org. The conda-forge channel in particular has a lot
> of
> additional packages.
> Hopefully that's more like what you're looking for.
> Best,
> Ian Henriksen
> --
>
> 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:
> http://public.kitware.com/mailman/listinfo/cmake-developers
-- 

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:
http://public.kitware.com/mailman/listinfo/cmake-developers