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 enou
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
your problem.
On Fri, Jan 27, 2017 at 12:58 PM, Hendrik Sattler
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
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 li
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
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,
>
Ooops, this message was supposed to be "Reply All"
-- Forwarded message ------
From: Elizabeth A. Fischer
Date: Fri, Dec 23, 2016 at 3:28 PM
Subject: Re: [CMake] cmake vs. Python 3.4
To: Lev
Look for a binary called `python3`, not `python`. See here:
https://github.co
>
> 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.
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
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
> env
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 wil
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 requir
>
> 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
>
> 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
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
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+
ect. 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
> wrote:
> > On Wed, 15 Jun 2016 10:50:13 -0400
> > "Elizabeth
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 Boettch
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 ot
19 matches
Mail list logo