llvm-3.7 release and OpenMP

[Jeremy Huddleston Sequoia]

> On Sep 3, 2015, at 10:51, Sean Farley <sean at macports.org> wrote:
> 
> 
> Jeremy Huddleston Sequoia <jeremyhu at macports.org> writes:
> 
>>> On Sep 3, 2015, at 10:32, Sean Farley <sean at macports.org> wrote:
>>> 
>>> 
>>> Jeremy Huddleston Sequoia <jeremyhu at macports.org> writes:
>>> 
>>>>> On Sep 3, 2015, at 09:21, Jack Howarth <howarth.at.macports at gmail.com> 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.
>>> 
>>> 
>>> How? I only see these as dependencies for cmake:
>>> 
>>> $ port rdeps cmake
>>> The following ports are dependencies of cmake @3.3.1_0:
>>> curl
>>>   pkgconfig
>>>     libiconv
>>>       gperf
>>>   zlib
>>>     xz
>>>       gettext
>>>         expat
>>>         ncurses
>>>   openssl
>>>   curl-ca-bundle
>>>     perl5
>>>       perl5.16
>>>         gdbm
>>> bzip2
>>> libarchive
>>>   libxml2
>>>   lzo2
>>> 
>>> I see that libomp depends on cmake but cmake doesn't depend on libomp
>>> nor llvm so how is it a cycle?
>> 
>> You're not looking at build dependencies.
>> 
>> On older OS veersions, cmake requires either macports-clang-X.Y (for libc++ clients) or macports-gcc-X.Y (for libstdc++ clients) to compile due to its C++11 requirement.
> 
> Ah, I see more dependencies now. The only C++11 requirements I see
> though are with the 'gui' variant. So, wouldn't we be able to depend on
> 'cmake -gui' or am I missing something else?

We don't have support for expressing that well in base, so I'm just very conservative about bringing in any dependencies into the toolchain.  I'm happy to add non-default variants to llvm and clang, but adding a new dependency (especially one that can bring in both perl and python) is a bit scary. =/

Note that building a newer toolchain on Tiger is a bit of a challenge, and we ended up using a +bootstrap variant in the apple-gcc42 port to help out with that, but I'd prefer not to have to resort to such tactics for more recent OS versions.  Specifically, I'd prefer to not have to tell people to install cmake -gui, then clang-3.7, then cmake with their desired variants.

I guess it would be ok to have such users use clang-3.4 to build cmake to build clang-3.8, but that's also sub-optimal.  I'm certainly not against it, though, since it is only an issue for older OS versions.

If you (or someone else) wants to take a shot at this, please do so.  I think at minimum, we'd need to:
    a) Update the llvm-3.8 port with a dependency on port:cmake and relevant other changes
    b-1) Update the cmake port to check if clang-3.8 is installed and blacklist it if it isn't
    b-2) Come up with a better way (in base) of ensuring that a compiler is not used to satisfy its own dependencies if it is not already installed

--Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4118 bytes
Desc: not available
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20150903/1286f488/attachment.p7s>