Re: [CMake] Building third party libraries along with normal targets

[Elizabeth A. Fischer]

Miller,

Thank you for your input; I'm hoping we can use it to improve our
description of Spack at http://spack.io  .  I'm cross-posting to the Spack
list, maybe someone there can add to this.

https://github.com/LLNL/spack/issues/2115

There has been talk of a comparison; but I'm not familiar enough with the
other systems to talk about them.  I can/will say a bit about Spack.


>
but none actually have defined the problem or their solution.


Spack is aimed at people involved in scientific computing.  This is more a
social distinction than technical: there is nothing particularly special
about scientific software environments, and I know of corporate
environments that are considering Spack as well.  However, this intended
audience does drive the design in some ways.

1. As with Macports, Homebrew, Gentoo, etc. Spack is focused on building
things from source.  There has been some work on packing up Spack builds as
RPMs so they can be quickly installed across multiple machines.

2. Spack supports cross-compilers.  Cross compilation is an intrinsic part
of some supercomputers, in which the login nodes are a different
architecture from the nodes the software runs on.  Maybe a Spacker who has
done cross-compiling can speak up here...

3. Spack supports multiple versions of installed packages --- where the
"version" is actually a hash of the package version, plus the version of
all its dependencies.  Central to Spack is the "concretization" algorithm,
which chooses which version of each package to build for you, based on the
constraints you give it.  For example, you could build 24 versions of
NetCDF, based on different compilers and MPI options you choose.  This kind
of flexibility is incredibly useful in a scientific environment, where
different top-level applications require different versions of various
underlying dependencies.
AFAIK, this concretization algorithm unique among auto-builders;
and it deserves some time to think about (look at the Powerpoint
presentations on the Spack page).  More common are builders (eg, those used
for Linux distros) that produce a *single* version of each desired package
--- and you have to manually specify the version of each package you want.
This is the step that Spack does automatically for you.



> what packages they create,


Spack now has over 1000 packages it knows how to build:

https://github.com/LLNL/spack/tree/develop/var/spack/repos/builtin/packages

NOTE: Be careful when comparing how many packages an auto-builder can
create.  Some package managers, for example, have a different "package" for
each version that might be installed.  For example, *netcdf-1.0*,
*netcdf-1.1*, *netcdf-1.2*, etc.  In Spack, each "package" corresponds to
an upstream piece of software (i.e. just *netcdf)*, and Spack knows how to
install potentially many versions and variants of it*.*


> what compromises they make,



> what they expect of my environment...


Just Python 2.6 or 2.7: do a "git clone", then run, starting up is very
easy.  Spack needs other basic tools as well (*git*, *curl*, etc.).  On
newer systems, they "just work"; on older systems, Spack can be used to
install them.


limitations


1. Spack currently runs on Linux + MacOS, not Windows.

2. Spack doesn't really know how to work with sub-package managers: eg,
using Spack to install `pip`, and then using `pip` to install things.  Same
thing for `luarocks`, `conda`, `node-js`, etc.  Spack *can* install these
things, just don't expect great integration.  We've thought a lot about how
to integrate well, and haven't come up with any home run ideas.  The issue
is most significant with *node-js* when a Spack package wants to depend on
a bunch of Javascript packages.

3. Spack's concretization algorithm, while still much faster than a human,
is too slow to conveniently use for software stacks of greater than ~100
packages.  This also makes it less than ideal for the Javascript world,
where packages are small and numerous.


> the other 10% of the time our system has an imcompatible version of some
> library and things blow up when you try to use some uncommon feature).


Spack goes to great lengths to build all dependencies itself, and not
"accidentally" depend on system-supplied software.

This is getting off-topic for the cmake mailing list, but I don't know
> where else to move the conversation.
>

Feel free to join the Spack mailing list (CC'd above).

-- Elizabeth
-- 

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] Building third party libraries along with normal targets

[Elizabeth A. Fischer]

I do this using the spack autobuilder.  Only problem is it doesn't run on
windows.  Maybe Conda?
On Mar 30, 2017 9:45 AM, "Robert Dailey"  wrote:

> On Thu, Mar 30, 2017 at 3:42 AM, Tamás Kenéz 
> wrote:
> > An alternative to the CMake superbuild: leave your actual project intact.
> > Simply create a separate shell script which builds all the dependencies
> (by
> > running cmake commands). Or, if you do like the ExternalProject stuff,
> > create a superbuild which builds only the dependencies.
>
> Problem with that is that it's not a portable solution. The #1 benefit
> of using CMake superbuilds (supplied with CMake build solution for the
> target library) is that it will function correctly on all platforms.
> --
>
> 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] Comaptibility with older gcc

[Elizabeth A. Fischer]

C++ code is not compatible between different compilers.  You cannot link
C++ code built with GCC 4.9.3 with GCC 4.2.1.  Maybe if you hack around and
find the GNU C++ libraries from your GCC 4.9.3 installation... just maybe,
with enough hacking, it will work.  But in general, this is a rabbit hole
that will offer you very little in the end.

The standard way to build on systems that don't have the compilers you need
is... to get the compilers you need.  My point was that getting these
compilers is actually not very hard.  In the end, that will almost
certainly be the easiest solution to your problem.


On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler <p...@hendrik-sattler.de>
wrote:

> Your answer is totally unrelated to the question.
>
> Am 27. Januar 2017 18:23:39 MEZ schrieb "Elizabeth A. Fischer" <
> elizabeth.fisc...@columbia.edu>:
> >Get spack, then use it to build GCC 4.9.3  takes a couple hours of wall
> >time, five minutes of your time.
> >
> >Github.com/llnl/spack
> >On Jan 27, 2017 12:04 PM, "Michele Portolan" <
> >michele.porto...@grenoble-inp.fr> wrote:
> >
> >> I have a project that build correctly using gcc 4.9.3, generating a
> >> dynamic library that I can later link to obtain my executables. So,
> >nothing
> >> special.
> >>
> >> My problem is that on one of my target systems, I only have a gcc
> >4.1.2
> >> and I am forced to use it for at least  linking the last executable.
> >My
> >> project uses extensively C++14,so I cannot build it with the older
> >gcc.
> >>
> >> Is there a way to have Cmake generate a library that is compatible
> >with
> >> gcc 4.1.2?
> >>
> >> Regards,
> >>
> >>
> >> Michele
> >> --
> >>
> >> 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/opensou
> >> rce/opensource.html
> >>
> >> Follow this link to subscribe/unsubscribe:
> >> http://public.kitware.com/mailman/listinfo/cmake
> >>
>
> --
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> gesendet.
>
-- 

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] Comaptibility with older gcc

[Elizabeth A. Fischer]

Get spack, then use it to build GCC 4.9.3  takes a couple hours of wall
time, five minutes of your time.

Github.com/llnl/spack
On Jan 27, 2017 12:04 PM, "Michele Portolan" <
michele.porto...@grenoble-inp.fr> wrote:

> I have a project that build correctly using gcc 4.9.3, generating a
> dynamic library that I can later link to obtain my executables. So, nothing
> special.
>
> My problem is that on one of my target systems, I only have a gcc 4.1.2
> and I am forced to use it for at least  linking the last executable. My
> project uses extensively C++14,so I cannot build it with the older gcc.
>
> Is there a way to have Cmake generate a library that is compatible with
> gcc 4.1.2?
>
> Regards,
>
>
> Michele
> --
>
> 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/opensou
> rce/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] Managing a local installation of cmake-built open source packages

[Elizabeth A. Fischer]

Aldi,


> I believe spack is the closest to what I need. However, all these
> solutions (hunter, conan, spack...) have perhaps their strongest focus
> in packaging, dependencies, automatic downloads, etc... while I prefer
> to do all such tasks myself.  I prefer to not have packages, just

download the source in the original developer provided form, untar it,
> and to even build it on my own, following the developer instructions.
>

That is exactly what Spack does.  A Spack "package" is really just a recipe
that automates those tasks.  I think of the Spack recipe as a Python
encoding of the English-language build instructions.  In fact, when I want
to know how a package is built, I prefer to look at the Spack recipe.  It's
more concise than English, and frequently more complete.


> As I said, I think spack is the closest. However, I feel it tries to
> automate too much the build. Yes, it gives you a lot of customization
> options, but I'm not sure the complexity is worth the effort.
>

Spack should work out-of-the-box without customizing things.  Many of the
features --- shell integration, environment modules, etc --- are not
strictly necessary.

You might be interested in the `spack setup` command, which currently works
with CMake-based projects.  It is especially good for projects you're
developing, or otherwise already have the source code in your directory.  I
use this feature to configure all the projects I'm working on.  To use
Spack setup, you do the following:

 1. Download and untar the software yourself, in your favorite location.
 (This is especially useful for development versions that don't yet have a
tarball).
 2. Run `spack setup`.  This creates a script whose purpose it is to call
CMake with appropriate options for dependencies and install location.
 3. Run the Spack-generated script in place of CMake
 4. Build and install yourself.

http://spack.readthedocs.io/en/latest/workflows.html?highlight=spack%20setup

Here's an example...
$ tar xvfz myproject.tar.gz
$ cd myproject
$ spack setup myproject@develop
$ mkdir build
$ cd build
$ ../spconfig.py ..   # Calls through to CMake
$ make
$ make install


> I think that by using this approach, I could reconsider moving to
> spack in the future (I'd likely have to install all packages from
> scratch if I move to spack later, but my directory hierarchy will end
> up being the same, so all the work I do now -writing code and
> projects- would be reusable without modification).
>

With an auto-builder, I've found that re-installing everything is no big
deal.  I can re-install 100 packages in a few hours of wall time, and no
more than a few minutes of my time.

-- Elizabeth
-- 

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] Managing a local installation of cmake-built open source packages

[Elizabeth A. Fischer]

Ardi,

What you describe is pretty much what Spack does.  I would take a look at
it, see if it meets your needs.  Chances are, at least some of the packages
you need are already included in Spack:

https://github.com/llnl/spack

-- Elizabeth

On Wed, Jan 18, 2017 at 12:39 PM, ardi  wrote:

> Hi,
>
> I want to install (on UNIX-like systems) a collection of open source
> packages which use cmake as the build tool, but I need the
> installation to be performed in a local directory (inside my home
> directory), and I wish convenient updating to new versions of the
> packages.
>
> I didn't arrive to a convincing solution, so any advice will be welcome.
>
> Here are my thoughts:
>
> The trivial solution is of course to directly install to a non-root
> prefix when invoking cmake, but, however, this isn't well suited for
> updating a previous installation of the packages (building and
> installing a new version will only overwrite files that have the same
> name, but it will keep old files that no longer exist in the new
> version, cluttering the local installation directory with no longer
> needed and mismatched files).
>
> A possibility would be to keep a copy of install_manifest.txt whenever
> I install a package, and remembering to always run 'xargs rm <
> install_manifest.txt' before installing a different version of a
> previously installed package.
>
> But keeping the install_manifest.txt of each installed package (and
> using it before updating a package) looks like a too-manual task,
> candidate to some kind of automation.
>
> Another (perhaps wiser) possibility would be to use cpack for creating
> either a RPM or DEB, and then use the corresponding package manager to
> install the package. But this has problems too: most package managers
> assume a / root installation directory. Also, I use several OSs: OSX,
> Linux, and some BSDs, and I'm not sure that either the RPM nor the DEB
> pkg managers will work flawlessly across all the OSs I use.
>
> What would you recommend here?
>
> Thanks a lot!
> --
>
> 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

[CMake] Fwd: cmake vs. Python 3.4

[Elizabeth A. Fischer]

Ooops, this message was supposed to be "Reply All"

-- Forwarded message ------
From: Elizabeth A. Fischer <elizabeth.fisc...@columbia.edu>
Date: Fri, Dec 23, 2016 at 3:28 PM
Subject: Re: [CMake] cmake vs. Python 3.4
To: Lev <leventel...@gmail.com>


Look for a binary called `python3`, not `python`.  See here:

https://github.com/citibeth/icebin/blob/develop/cmake/FindPython.cmake

The `FindPython.cmake` I shared above also queries the Python system for
the correct place to install things.  See here for how it's used:

https://github.com/citibeth/icebin/blob/develop/pylib/CMakeLists.txt


On Fri, Dec 23, 2016 at 2:57 PM, Lev <leventel...@gmail.com> wrote:

> Hi list,
>
>
> I have this:
>
> FIND_PACKAGE(PythonInterp)
>
> and cmake finds this:
>
> -- Found PythonInterp: /usr/bin/python (found version "2.7.9")
>
> However, 3.4 is also installed. How can I specify to find 3.4?
>
> If I say:
>
> set(Python_ADDITIONAL_VERSIONS 3.4)
> FIND_PACKAGE(PythonInterp 3 REQUIRED)
>
> still no luck.
>
> This is on a Debian stable, so
>
> $ cmake --version
> cmake version 3.0.2
>
>
> Thanks,
> Levente
>
> --
> 73 de HA5OGL
> Op.: Levente
> --
>
> 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/opensou
> rce/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] cmake vs. Python 3.4

[Elizabeth A. Fischer]

>
> Try using the update-alternatives command so that "python" becomes
> symbolically linked to python-3.4 rather than python-2.7.9
>
> Or uninstall python 2.7.9.
>

The standard Python distribution for versions 3 or greater installs a
binary called `python3`, not `python`.  That is the standard.  If you are
running Python3 from a binary called `python`, that is not standard.  I
know that distros do this (or can do it with tweaking); but that doesn't
make it standard.  If you want to be sure you're getting Python3, you
should look for a binary called `python3`.

Does FindPython not have logic to check the versioned pythonx.y
> alternatives when doing these checks?  Why isn't it checking the python3
> and python3.x commands in this circumstance?


Have you tried the FindPython I referenced above?  It would solve the
problems you brought to this thread (and maybe even some you didn't yet
know you have).
-- 

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] Issue with Fortran/C binding with Intel compilers

[Elizabeth A. Fischer]

Can you use the Fortran/C interop that is now an ISO standard for Fortran
2003 and beyond?  That should eliminate the issues you're facing here.

https://gcc.gnu.org/onlinedocs/gfortran/Interoperability-with-C.html


On Thu, Nov 17, 2016 at 8:50 AM, Joachim Pouderoux <
joachim.pouder...@kitware.com> wrote:

> Hi,
>
> I am using something like this in my CMake script:
>   enable_language(Fortran)
>   include(FortranCInterface)
>   FortranCInterface_VERIFY()
>   FortranCInterface_HEADER(${CMAKE_CURRENT_BINARY_DIR}/FortranBinding.h
> MACRO_NAMESPACE "FC_"
> SYMBOL_NAMESPACE "FC_")
>
> So far, with gfortran/gcc/clang, I never had any issues and the generated
> FortranBinding.h is correct, defining FC_GLOBAL, FC_GLOBAL_, FC_MODULE and
> FC_MODULE_ macros.
> However, I am facing issues with Intel compilers (icc+ifort) (I am using
> v17.0.0), VERIFY macro claims that it is OK but then, the FortranBinding.h
> header is empty (only the #ifndef,#define,#endif stuff), no macro
> definition.
> Any idea?
>
> Thanks!
> Best,
>
> *Joachim Pouderoux*, PhD
>
> *Technical Expert - Scientific Computing Team*
> *Kitware SAS *
>
>
> --
>
> 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] Building CMake without Curl

[Elizabeth A. Fischer]

Jayesh,

Use Spack.  Spack has no problem auto-building CMake for you, along with
curl and whatever else it needs.

https://github.com/llnl/spack/

-- Elizabeth


On Wed, Nov 2, 2016 at 1:08 PM, Jayesh Badwaik 
wrote:

> Hi,
>
> Is there a way to build CMake without curl? I am currently in an
> environment
> where I have no openssl-dev packages nor libcurl-dev packages. So, if I
> want
> to build CMake, I will need to build openssl-dev myself which I do not
> want to
> do.
>
> I can ask my sysadmin for the packages, but I was wondering if there is
> another method. A follow up question would be, if this is not possible,
> why is
> libcurl essential to Cmake?
>
>
> --
> Cheers
> Jayesh Badwaik
> https://www.jayeshbadwaik.in
> --
>
> 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] [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 

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-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 <rcdailey.li...@gmail.com>
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
> <elizabeth.fisc...@columbia.edu> 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" <rcdailey.li...@gmail.com>
> 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.
> >> --
> >>
> >> Po

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 <rcdailey.li...@gmail.com>
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
> <elizabeth.fisc...@columbia.edu> 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" <rcdailey.li...@gmail.com>
> 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.
> >> --
> >>
> >> Po

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

[Elizabeth A. Fischer]

>
> This is what Spack and other meta builders do.  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.
>
See http://github. com/llnl/spack
>

-- Elizabeth
-- 

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]

>
> This is what Spack and other meta builders do.  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.
>
See http://github. com/llnl/spack
>

-- Elizabeth
-- 

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

[Elizabeth A. Fischer]

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

Re: [CMake] CXX_STANDARD and -std=c++14

[Elizabeth A. Fischer]

At the risk of repeating myself... it's a non-intuitive "gotcha" that

 set_property(TARGET target PROPERTY CXX_STANDARD 14)

results in something OTHER than the C++14 standard.  The issue is likely to
continue tripping people up, resulting in continued posts to this email
list.  If you want C++14 with GNU extensions, you should have to do
something like:

 set_property(TARGET target PROPERTY CXX_STANDARD GNU14)

which would throw an error if you try it with any non-GNU compiler.

-- Elizabeth


On Thu, Jun 23, 2016 at 8:37 AM, James Swift  wrote:

> Thanks, Nicholas.
>
> Might be worth adding a link to that from this page.
>
>
> https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html?highlight=cxx_standard
>
> On 23 June 2016 at 14:34, Nicholas Braden 
> wrote:
>
>> This was asked recently - have a look at the CXX_EXTENSIONS property:
>> https://cmake.org/cmake/help/latest/prop_tgt/CXX_EXTENSIONS.html
>>
>> Previous discussion:
>> http://public.kitware.com/pipermail/cmake/2016-June/063691.html
>>
>> On Thu, Jun 23, 2016 at 7:27 AM, James Swift  wrote:
>> > Hi,
>> >
>> > is there a way (or can it be added) to get set_property(TARGET target
>> > PROPERTY CXX_STANDARD 14) to output -std=c++14 and not -std=gnu++14 when
>> > needed?
>> >
>> > Thanks,
>> > James Swift
>> >
>> >
>> > --
>> >
>> > 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
>
-- 

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] GCC: -std=g++14 vs -std=c++14

[Elizabeth A. Fischer]

That seems wrong to me.  Regardless of how proud the  compiler makers are
of their extensions, the language you're using should depend as little as
possible (by default) on the compiler you choose.
-- Elizabeth

On Wed, Jun 15, 2016 at 11:48 AM, Robert Maynard <robert.mayn...@kitware.com
> wrote:

> This is correct. The default for GCC has always been to enable gcc
> extensions, with GCC < 6 having a default of gnu++98, and GCC 6 having
> a default of gnu++14
>
> On Wed, Jun 15, 2016 at 11:00 AM, Patrick Boettcher
> <patrick.boettc...@posteo.de> wrote:
> > On Wed, 15 Jun 2016 10:50:13 -0400
> > "Elizabeth A. Fischer" <elizabeth.fisc...@columbia.edu> wrote:
> >
> >> Why are these extensions not turned off by default?  Normally, things
> >> should conform to the standards out-of-the-box; and you should have to
> >> explicitly enable extensions.  Following that principle would have
> >> avoided this entire thread.
> >
> > Well, I'd not be surprised if the expected standard for gcc users is
> > --std=gnu++14 instead of --std=c++14 . That could be a good explanation.
> >
> > regards,
> > --
> > Patrick.
> > --
> >
> > 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] GCC: -std=g++14 vs -std=c++14

[Elizabeth A. Fischer]

Why are these extensions not turned off by default?  Normally, things
should conform to the standards out-of-the-box; and you should have to
explicitly enable extensions.  Following that principle would have avoided
this entire thread.

-- Elizabeth

On Wed, Jun 15, 2016 at 1:50 AM, Patrick Boettcher <
patrick.boettc...@posteo.de> wrote:

> On Mon, 13 Jun 2016 20:05:23 +0200
> Patrick Boettcher  wrote:
> > > You also need to correctly set the CXX_EXTENSIONS properties to get
> > > a standard standard.
> >
> > Yep,
> >
> >   set(CXX_EXTENSIONS OFF)
> >
> > seems to do the trick - thanks.
>
> Well, it is
>
>   set(CMAKE_CXX_EXTENSIONS OFF)
>
> actually. Before the target-definition (add_library or add_executable).
>
>
> --
> Patrick.
> --
>
> 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] Provide configuration settings for users

[Elizabeth A. Fischer]

Cedric,

I would highly recommend an auto-builder such as Spack as a good way to
have a system that automatically downloads and installs dependencies for
your software.  My software requires about 50 dependencies (once recursive
dependencies are counted), and I've successfully used Spack to have others
install it.  See instructions for installing my software stack using Spack
at:

   https://github.com/citibeth/icebin

(Most of these instructions are for bootstrapping Spack on old machines,
and not directly for my particular software).

This approach is a lot easier for you and your users, and more flexible to
boot:

 1. You don't have to deal with advanced/esoteric features like
ExternalProject, CMakeList templates, etc.

 2. It doesn't matter what build system your dependencies were written
with.  (I've heard of people writing CMake builds for all their
dependencies.  As much as I like CMake, that seems like a painful way to
proceed).

 3. Consider what would happen if every project used ExternalProject for
its dependencies: we'd be unable to link projects together as soon as they
share a sub-dependency, since every project would be building its own.  You
really want to build a coherent software DAG (Directed Acyclic Graph) at a
level ABOVE the single-project level, in order to avoid duplicate /
conflicting packages in your build.  For that reason, the project-building
level (CMake) is fundamentally the wrong place to do this.  It should be
done by auto-builders on top of the project level (Spack, EasyBuild,
MacPorts, Gentoo Portage, etc).

-- Elizabeth



On Tue, Jun 14, 2016 at 6:28 AM, Cedric Doucet 
wrote:

>
> Hello,
>
> is there a native way to provide configuration settings for the users of a
> software?
>
> For example, I develop a software which depends on several 3rd party
> libraries which are automatically downloaded and installed with the
> ExternalProject module.
> My CMake configuration scripts are written so as to handle these 3rd party
> libraries.
> During installation of the software, header files and libraries are copied
> to the destination directory but (of course) without their 3rd party
> dependencies.
>
> Therefore, if a user wants to use my software, he has to handle these 3rd
> party libraries during compilation and linking steps.
> Depending on the skills of the user, it may be difficult to achieve it.
>
> I would like to know if there exists a native way of providing sufficient
> configuration information so that users do not have to handle these
> libraries.
> For the moment, I provide a CMakeLists template but I wonder if it's the
> best possible solution.
>
> Best regards,
>
> Cédric Doucet
>
> --
>
> 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