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 <[email protected]> wrote: > >> 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 > > > _______________________________________________ > macports-dev mailing list > [email protected] > https://lists.macosforge.org/mailman/listinfo/macports-dev > _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
