[about shell script portability]
We do use shell-scripts on Windows since git-bash comes with git for free.
Our workflow is centered around the command-line (git-bash for Windows) and
you can run shell scripts in git-bash, that's why compatibility is not a
problem. All our scripts and workflows
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
gt; Sent: Wednesday, March 29, 2017 9:39 PM
> To: Florent Castelli <florent.caste...@gmail.com>
> Cc: CMake <cmake@cmake.org>
> Subject: Re: [CMake] Building third party libraries along with normal targets
>
> On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli
> <flo
<florent.caste...@gmail.com>
Cc: CMake <cmake@cmake.org>
Subject: Re: [CMake] Building third party libraries along with normal targets
On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli <florent.caste...@gmail.com>
wrote:
> On 30/03/2017 03:54, Robert Dailey wrote:
>>
>>
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:
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
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.
Tamas
On Thu, Mar
On 30/03/2017 04:38, Robert Dailey wrote:
At the end of the day, I've solved the Boost problem but I have many
other libraries I still manually build: openssl, libpng, zlib, etc.
It's as you said, maintaining build scripts for all of these will be
challenging but I think that's the proper way to
On Wed, Mar 29, 2017 at 9:32 PM, Florent Castelli
wrote:
> On 30/03/2017 03:54, Robert Dailey wrote:
>>
>> On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
>> wrote:
>>>
>>> This is known as "super build".
>>> Yes, this is exactly why I
On 30/03/2017 03:54, Robert Dailey wrote:
On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
wrote:
This is known as "super build".
Yes, this is exactly why I made my Boost CMake build scripts, which you use
unless you changed your mind today :)
You mean this?
On Wed, Mar 29, 2017 at 8:18 PM, Florent Castelli
wrote:
> This is known as "super build".
> Yes, this is exactly why I made my Boost CMake build scripts, which you use
> unless you changed your mind today :)
You mean this?
https://github.com/Orphis/boost-cmake
It's
On 30/03/2017 02:10, Robert Dailey wrote:
Interested in hearing everyone's thoughts on this idea of mine.
Right now I have several third party libraries: openssl, boost,
libpng, zlib, etc. List goes on. I need to support these libraries on
at least 3 different platforms: ARM android, x86 linux,
12 matches
Mail list logo