[Cmake-commits] CMake branch, master, updated. v3.6.1-616-g5726af6

[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  5726af681a9eb9b1c8d2a1bee4c5c93e61f6e109 (commit)
  from  77c171a37ce005399c8b81b32721f6e167a78913 (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=5726af681a9eb9b1c8d2a1bee4c5c93e61f6e109
commit 5726af681a9eb9b1c8d2a1bee4c5c93e61f6e109
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Sun Aug 14 00:01:03 2016 -0400
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Sun Aug 14 00:01:03 2016 -0400

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 8481ce2..b963882 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 20160813)
+set(CMake_VERSION_PATCH 20160814)
 #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-developers] [CMake] Need ideas/opinions on third party library management

[Ian Henriksen]

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

[cmake-developers] [PATCH v6] For Windows encode process output to internally used encoding

[Dāvis Mosāns]

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).
---
 Source/CMakeLists.txt  |   2 +
 Source/ProcessOutput.hxx.in| 160 +
 Source/cmExecProgramCommand.cxx|   3 +
 Source/cmExecuteProcessCommand.cxx |  11 ++-
 Source/cmProcessTools.cxx  |   9 ++-
 Source/cmSystemTools.cxx   |  11 ++-
 bootstrap  |   3 +
 7 files changed, 193 insertions(+), 6 deletions(-)
 create mode 100644 Source/ProcessOutput.hxx.in

diff --git a/Source/CMakeLists.txt b/Source/CMakeLists.txt
index a790994..eb51683 100644
--- a/Source/CMakeLists.txt
+++ b/Source/CMakeLists.txt
@@ -419,6 +419,8 @@ foreach(command_file
 endforeach()
 configure_file(cmCommands.cxx.in ${CMAKE_CURRENT_BINARY_DIR}/cmCommands.cxx 
@ONLY)
 
+configure_file(ProcessOutput.hxx.in 
${CMAKE_CURRENT_BINARY_DIR}/ProcessOutput.hxx)
+
 # Kdevelop only works on UNIX and not windows
 if(UNIX)
   set(SRCS ${SRCS} cmGlobalKdevelopGenerator.cxx)
diff --git a/Source/ProcessOutput.hxx.in b/Source/ProcessOutput.hxx.in
new file mode 100644
index 000..ea7b881
--- /dev/null
+++ b/Source/ProcessOutput.hxx.in
@@ -0,0 +1,160 @@
+/*
+  CMake - Cross Platform Makefile Generator
+  Copyright 2000-2016 Kitware, Inc., Insight Software Consortium
+
+  Distributed under the OSI-approved BSD License (the "License");
+  see accompanying file Copyright.txt for details.
+
+  This software is distributed WITHOUT ANY WARRANTY; without even the
+  implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+  See the License for more information.
+*/
+#ifndef ProcessOutput_hxx
+#define ProcessOutput_hxx
+
+#include 
+#include 
+#if defined(_WIN32)
+#  ifndef WIN32_LEAN_AND_MEAN
+#define WIN32_LEAN_AND_MEAN 1
+#  endif
+#  include 
+#endif
+
+  class ProcessOutput
+  {
+public:
+#if defined(_WIN32)
+  static const UINT defaultCodepage = @KWSYS_ENCODING_DEFAULT_CODEPAGE@;
+#endif
+  // must match to KWSYSPE_PIPE_BUFFER_SIZE
+  ProcessOutput(unsigned int maxSize = 1024)
+  {
+#if defined(_WIN32)
+bufferSize = maxSize;
+codepage = GetConsoleCP();
+if (!codepage) {
+  codepage = GetACP();
+}
+#else
+static_cast(maxSize);
+#endif
+  }
+
+  ~ProcessOutput()
+  {
+  }
+
+  bool DecodeText(std::string raw, std::string& decoded, size_t id = 0)
+  {
+bool success = true;
+decoded = raw;
+#if defined(_WIN32)
+if (id > 0) {
+  if (rawparts.size() < id) {
+rawparts.reserve(id);
+while (rawparts.size() < id) rawparts.push_back(std::string());
+  }
+  raw = rawparts[id - 1] + raw;
+  rawparts[id - 1].clear();
+  decoded = raw;
+}
+if (raw.size() > 0 && codepage != defaultCodepage) {
+  success = false;
+  CPINFOEXW cpinfo;
+  if (id > 0 && raw.size() == bufferSize && GetCPInfoExW(codepage, 0, 
) == 1 && cpinfo.MaxCharSize > 1) {
+if (cpinfo.MaxCharSize == 2 && cpinfo.LeadByte[0] != 0) {
+  LPSTR prevChar = CharPrevExA(codepage, raw.c_str(), raw.c_str() 
+ raw.size(), 0);
+  bool isLeadByte = (*(prevChar + 1) == 0) && 
IsDBCSLeadByteEx(codepage, *prevChar);
+  if (isLeadByte) {
+rawparts[id - 1] += *(raw.end() - 1);
+raw.resize(raw.size() - 1);
+  }
+  success = DoDecodeText(raw, decoded, NULL);
+} else {
+  bool restoreDecoded = false;
+  std::string firstDecoded = decoded;
+  wchar_t lastChar = 0;
+  for (UINT i = 0; i < cpinfo.MaxCharSize; i++) {
+success = DoDecodeText(raw, decoded, );
+if (success && lastChar != 0) {
+  if (i == 0) {
+firstDecoded = decoded;
+  }
+  if (lastChar == cpinfo.UnicodeDefaultChar) {
+restoreDecoded = true;
+rawparts[id - 1] = *(raw.end() - 1) + rawparts[id - 1];
+raw.resize(raw.size() - 1);
+  } else {
+restoreDecoded = false;
+break;
+  }
+} else {
+  break;
+}
+  }
+  if (restoreDecoded) {
+decoded = firstDecoded;
+rawparts[id - 1].clear();
+  }
+}
+  } else {
+success = DoDecodeText(raw, decoded, NULL);
+  }
+}
+#else
+static_cast(id);
+#endif
+return success;
+  }
+
+  bool 

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

[Robert Dailey]

Wow I actually completely forgot about that lol. I think I was looking
into it for some other reasons, not related to work. I will have to
look into it again. I don't really remember much about it.

Thanks for the reminder.

On Sat, Aug 13, 2016 at 7:02 PM, Ruslan Baratov
 wrote:
> Hi, Robert
>
> According to your GitHub account you've send a trivial patch about a year
> ago to the Hunter (https://github.com/ruslo/hunter) package manager. So I
> wonder what is your experience, have you tried it? Have you run into some
> troubles?
>
> Thanks, Ruslo
>
>
> On 12-Aug-16 22: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 way (such
>> as boost). For this reason we do not rely on our external environment
>> or external package managers to fulfill third party dependencies, like
>> most open source projects do on Linux for example.
>>
>> Does this "Super Build" approach sound like a better idea? What other
>> options are available? The downside with the "Super Build" solution is
>> that it will become very difficult to make the transition between
>> building third party and building our code base seamless. I can't do
>> both in the same generate step because find_package() can't be called
>> until the libraries are built & installed.
>
>
>
-- 

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]

Hi, Robert

According to your GitHub account you've send a trivial patch about a 
year ago to the Hunter (https://github.com/ruslo/hunter) package 
manager. So I wonder what is your experience, have you tried it? Have 
you run into some troubles?


Thanks, Ruslo

On 12-Aug-16 22: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 way (such
as boost). For this reason we do not rely on our external environment
or external package managers to fulfill third party dependencies, like
most open source projects do on Linux for example.

Does this "Super Build" approach sound like a better idea? What other
options are available? The downside with the "Super Build" solution is
that it will become very difficult to make the transition between
building third party and building our code base seamless. I can't do
both in the same generate step because find_package() can't be called
until the libraries are built & installed.



--

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

[Elizabeth A. Fischer]

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


On Sat, Aug 13, 2016 at 7:00 PM, Robert Dailey 
wrote:

> I did some brief digging into spack, and it doesn't look like it
> supports Windows. All I see are shell scripts and the documentation
> uses POSIX.
>
> If I'm going to use a package manager, it needs to be able to support
> Android (ARM), Windows, and Linux. I have specific toolchains that
> I'll need the package manager to use for each of these platforms,
> assuming it compiles these libraries. It also needs to be capable of
> cross-compiling (in the case of ARM toolchain in the Android NDK).
>
> I mean, we can't really call it "reinventing the wheel" if my
> requirements are so specific that no current tooling can support it.
> If you have any info on spack related to my requirements please let me
> know. It looks promising, but so far doesn't seem like it will work
> out.
>
> On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer
>  wrote:
> > This is what Spack and other meta builders do.  See http://github.
> > com/llnl/spack
> >
> > On Aug 12, 2016 3:59 PM, "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 way (such
> >> as boost). For this reason we do not rely on our external environment
> >> or external package managers to fulfill third party dependencies, like
> >> most open source projects do on Linux for example.
> >>
> >> Does this "Super Build" approach sound like a better idea? What other
> >> options are available? The downside with the "Super Build" solution is
> >> that it will become very difficult to make the transition between
> >> building third party and building our code base seamless. I can't do
> >> both in the same generate step because find_package() can't be called
> >> until the libraries are built & installed.
> >> --
> >>
> >> 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

[Elizabeth A. Fischer]

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


On Sat, Aug 13, 2016 at 7:00 PM, Robert Dailey 
wrote:

> I did some brief digging into spack, and it doesn't look like it
> supports Windows. All I see are shell scripts and the documentation
> uses POSIX.
>
> If I'm going to use a package manager, it needs to be able to support
> Android (ARM), Windows, and Linux. I have specific toolchains that
> I'll need the package manager to use for each of these platforms,
> assuming it compiles these libraries. It also needs to be capable of
> cross-compiling (in the case of ARM toolchain in the Android NDK).
>
> I mean, we can't really call it "reinventing the wheel" if my
> requirements are so specific that no current tooling can support it.
> If you have any info on spack related to my requirements please let me
> know. It looks promising, but so far doesn't seem like it will work
> out.
>
> On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer
>  wrote:
> > This is what Spack and other meta builders do.  See http://github.
> > com/llnl/spack
> >
> > On Aug 12, 2016 3:59 PM, "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 way (such
> >> as boost). For this reason we do not rely on our external environment
> >> or external package managers to fulfill third party dependencies, like
> >> most open source projects do on Linux for example.
> >>
> >> Does this "Super Build" approach sound like a better idea? What other
> >> options are available? The downside with the "Super Build" solution is
> >> that it will become very difficult to make the transition between
> >> building third party and building our code base seamless. I can't do
> >> both in the same generate step because find_package() can't be called
> >> until the libraries are built & installed.
> >> --
> >>
> >> 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

[Robert Dailey]

I did some brief digging into spack, and it doesn't look like it
supports Windows. All I see are shell scripts and the documentation
uses POSIX.

If I'm going to use a package manager, it needs to be able to support
Android (ARM), Windows, and Linux. I have specific toolchains that
I'll need the package manager to use for each of these platforms,
assuming it compiles these libraries. It also needs to be capable of
cross-compiling (in the case of ARM toolchain in the Android NDK).

I mean, we can't really call it "reinventing the wheel" if my
requirements are so specific that no current tooling can support it.
If you have any info on spack related to my requirements please let me
know. It looks promising, but so far doesn't seem like it will work
out.

On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer
 wrote:
> This is what Spack and other meta builders do.  See http://github.
> com/llnl/spack
>
> On Aug 12, 2016 3:59 PM, "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 way (such
>> as boost). For this reason we do not rely on our external environment
>> or external package managers to fulfill third party dependencies, like
>> most open source projects do on Linux for example.
>>
>> Does this "Super Build" approach sound like a better idea? What other
>> options are available? The downside with the "Super Build" solution is
>> that it will become very difficult to make the transition between
>> building third party and building our code base seamless. I can't do
>> both in the same generate step because find_package() can't be called
>> until the libraries are built & installed.
>> --
>>
>> 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 

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

[Robert Dailey]

I did some brief digging into spack, and it doesn't look like it
supports Windows. All I see are shell scripts and the documentation
uses POSIX.

If I'm going to use a package manager, it needs to be able to support
Android (ARM), Windows, and Linux. I have specific toolchains that
I'll need the package manager to use for each of these platforms,
assuming it compiles these libraries. It also needs to be capable of
cross-compiling (in the case of ARM toolchain in the Android NDK).

I mean, we can't really call it "reinventing the wheel" if my
requirements are so specific that no current tooling can support it.
If you have any info on spack related to my requirements please let me
know. It looks promising, but so far doesn't seem like it will work
out.

On Fri, Aug 12, 2016 at 3:41 PM, Elizabeth A. Fischer
 wrote:
> This is what Spack and other meta builders do.  See http://github.
> com/llnl/spack
>
> On Aug 12, 2016 3:59 PM, "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 way (such
>> as boost). For this reason we do not rely on our external environment
>> or external package managers to fulfill third party dependencies, like
>> most open source projects do on Linux for example.
>>
>> Does this "Super Build" approach sound like a better idea? What other
>> options are available? The downside with the "Super Build" solution is
>> that it will become very difficult to make the transition between
>> building third party and building our code base seamless. I can't do
>> both in the same generate step because find_package() can't be called
>> until the libraries are built & installed.
>> --
>>
>> 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