I was deferring to someone else the re-tool for cmake. ;) There also
seem to be many patchfiles that you've been maintaining, which I
haven't tried to grok at all...
Thanks,
- Eric
On Tue, Oct 13, 2015 at 2:51 AM, Jeremy Huddleston Sequoia
wrote:
> Hey Eric,
>
> Last month, you mentioned rewri
Hey Eric,
Last month, you mentioned rewriting the llvm Portfile to use the cmake build
system. I think now might be an opportune time to do that in llvm-3.8. Have
you looked into that yet?
--Jeremy
> On Sep 3, 2015, at 10:10, Eric A. Borisch wrote:
>
> I'll defer on rewriting the portfile
I've created a ticket with some additional info.
https://trac.macports.org/ticket/48759
Note that the subversion sync seems to not be running, but at least trac is up!
On Thu, Sep 3, 2015 at 1:12 PM, Jeremy Huddleston Sequoia
wrote:
>
>> On Sep 3, 2015, at 10:51, Sean Farley wrote:
>>
>>
>> Je
> On Sep 3, 2015, at 10:51, Sean Farley wrote:
>
>
> Jeremy Huddleston Sequoia writes:
>
>>> On Sep 3, 2015, at 10:32, Sean Farley wrote:
>>>
>>>
>>> Jeremy Huddleston Sequoia writes:
>>>
> On Sep 3, 2015, at 09:21, Jack Howarth
> wrote:
>
> You really will want to rew
Jeremy Huddleston Sequoia writes:
>> On Sep 3, 2015, at 10:32, Sean Farley wrote:
>>
>>
>> Jeremy Huddleston Sequoia writes:
>>
On Sep 3, 2015, at 09:21, Jack Howarth
wrote:
You really will want to rewrite the llvm37 Portfile to use a cmake
build.
>>>
>>> Not u
> On Sep 3, 2015, at 10:32, Sean Farley wrote:
>
>
> Jeremy Huddleston Sequoia writes:
>
>>> On Sep 3, 2015, at 09:21, Jack Howarth
>>> wrote:
>>>
>>> You really will want to rewrite the llvm37 Portfile to use a cmake
>>> build.
>>
>> Not unless we can depend on cmake existing out-of-tre
Jeremy Huddleston Sequoia writes:
>> On Sep 3, 2015, at 09:21, Jack Howarth wrote:
>>
>> You really will want to rewrite the llvm37 Portfile to use a cmake
>> build.
>
> Not unless we can depend on cmake existing out-of-tree. If we need to depend
> on port:cmake, that introduces cycles.
> On Sep 3, 2015, at 09:21, Jack Howarth wrote:
>
> You really will want to rewrite the llvm37 Portfile to use a cmake
> build.
Not unless we can depend on cmake existing out-of-tree. If we need to depend
on port:cmake, that introduces cycles.
--Jeremy
> The openmp 3.7 can be built in-tre
I'll defer on rewriting the portfile for cmake.
I guess I like having libomp separate for now as it's much quicker to
update (build) it stand-alone while it's still getting frequent
updates. Note that (apparently) llvm is also packaging the OpenMP
runtime separately for now -- see the pre-built bi
On Sep 3, 2015, at 12:21 PM, Jack Howarth wrote:
> You really will want to rewrite the llvm37 Portfile to use a cmake
> build. The openmp 3.7 can be built in-tree using cmake (with the
> sources placed at projects/openmp. Also the default for -fopenmp is
> still left as -fopenmp=libgomp in 3.7.0
You really will want to rewrite the llvm37 Portfile to use a cmake
build. The openmp 3.7 can be built in-tree using cmake (with the
sources placed at projects/openmp. Also the default for -fopenmp is
still left as -fopenmp=libgomp in 3.7.0 but this can be changed
with...
--- cfe-3.7.0.src/CMake
Looks good to me. Could you go ahead and push this to svn and also do similar
changes to the llvm-3.8 port for your openmp variant?
Thanks,
Jeremy
> On Sep 2, 2015, at 15:34, Eric A. Borisch wrote:
>
> Would have done a ticket, but with trac down
>
> Attached is a patch to update to the
Would have done a ticket, but with trac down
Attached is a patch to update to the released llvm/clang-3.7 (this comments
out the svn fetch code, removes the default +assertions, and adds checksums)
As OpenMP is one of the much discussed items that llvm-3.7 brings to the
table, I've added a +o
13 matches
Mail list logo
