Re: [CMake] Provide configuration settings for users

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

Re: [CMake] GCC: -std=g++14 vs -std=c++14

> 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 s

Re: [CMake] GCC: -std=g++14 vs -std=c++14

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

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

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

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

> > 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

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

ke 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, "Rober

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

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

Re: [CMake] Comaptibility with older gcc

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>: > >G

Re: [CMake] Comaptibility with older gcc

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

Re: [CMake] Managing a local installation of cmake-built open source packages

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

Re: [CMake] Managing a local installation of cmake-built open source packages

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

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

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

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

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

Re: [CMake] Issue with Fortran/C binding with Intel compilers

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 <

Re: [CMake] Building CMake without Curl

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?

[CMake] Fwd: cmake vs. Python 3.4

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

Re: [CMake] cmake vs. Python 3.4

> > 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.

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

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:

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

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

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

> > 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

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

ke 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, "Rober

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

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