> On Sep 3, 2015, at 10:51, Sean Farley <[email protected]> wrote: > > > Jeremy Huddleston Sequoia <[email protected]> writes: > >>> On Sep 3, 2015, at 10:32, Sean Farley <[email protected]> wrote: >>> >>> >>> Jeremy Huddleston Sequoia <[email protected]> writes: >>> >>>>> On Sep 3, 2015, at 09:21, Jack Howarth <[email protected]> >>>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
