search

RJVB / macstrop

RJVB's repository of alternative macports, with ports missing from or overriding those in the standard collection, including a set of KF5 ports.
20 stars 9 forks source link

Clang 4.0 is pulled in and cannot be built #29

Closed Tatsh closed 5 years ago

Tatsh commented 5 years ago

This affects a lot of the ports including Dolphin and systemsettings.

I have narrowed this down to a few dependencies, which blacklist compilers and makes MacPorts think it should pull in Clang 4.0. However, Clang 4.0 will not build at this time. And it does not seem necessary?

In the Dolphin port, I removed kcmutils and kcrash from kf5.depends_frameworks and I commented out the current depends_run-append line. Dolphin built fine but perhaps it's missing some features. It does run and looks okay, and is basically usable.

RJVB commented 5 years ago

However, Clang 4.0 will not build at this time.

Why is that?

There are a number of ports which will not build with older clang versions, which includes the clang version in my own Xcode. There was also an issue with symbol visibility but I think that must be fixed for newer Xcode clang versions now.

Can you figure out how MacPorts reports your xcode clang version so we can make sure it doesn't get blacklisted?

Tatsh commented 5 years ago

The only compiler I have is Clang from Apple with latest Xcode 10.1:

 $ clang --version
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
RJVB commented 5 years ago

What I'd like to know is what ports cause clang 4.0 to be pulled in. A priori I always add compiler selection code that will try to pull in the newest available stable version (currently 6.0) but only when necessary.

Do I understand correctly that these ports build OK when you remove the compiler selection code?

BTW, you can always override the automatic selection via the commandline, e.g. configure.compiler=clang.

Tatsh commented 5 years ago

kcmutils is one of them:

 $ port install -y kf5-kcmutils
For xorg-util-macros: skipping org.macports.main (dry run)
For m4: skipping org.macports.main (dry run)
--->  Computing dependencies for flex
--->  Dependencies to be installed: m4
For m4: skipping org.macports.main (dry run)
For flex: skipping org.macports.main (dry run)
--->  Computing dependencies for bison
--->  Dependencies to be installed: m4
For m4: skipping org.macports.main (dry run)
For bison: skipping org.macports.main (dry run)
--->  Computing dependencies for gindent
For gindent: skipping org.macports.main (dry run)
--->  Computing dependencies for xar
For xar: skipping org.macports.main (dry run)
--->  Computing dependencies for llvm-4.0
--->  Dependencies to be installed: xar
For xar: skipping org.macports.main (dry run)
For llvm-4.0: skipping org.macports.main (dry run)
For libomp: skipping org.macports.main (dry run)
For clang_select: skipping org.macports.main (dry run)
For ld64-xcode: skipping org.macports.main (dry run)
--->  Computing dependencies for ld64
--->  Dependencies to be installed: ld64-xcode
For ld64-xcode: skipping org.macports.main (dry run)
For ld64: skipping org.macports.main (dry run)
--->  Computing dependencies for clang-4.0
--->  Dependencies to be installed: clang_select ld64 ld64-xcode libomp llvm-4.0 xar
For clang_select: skipping org.macports.main (dry run)
For ld64-xcode: skipping org.macports.main (dry run)
For ld64: skipping org.macports.main (dry run)
For libomp: skipping org.macports.main (dry run)
For xar: skipping org.macports.main (dry run)
For llvm-4.0: skipping org.macports.main (dry run)
For clang-4.0: skipping org.macports.main (dry run)
--->  Computing dependencies for kf5-kcmutils
For kf5-kcmutils: skipping org.macports.main (dry run)
RJVB commented 5 years ago

OK, as I thought this isn't caused by a KF5 port. Instead, I left some crud in my port:mesa variant, which is an indirect dependency of kf5-kdeclarative for a single optional class (Plotter) in that framework.

I've pushed an update for that port which adds a variant so libepoxy becomes an optional dependency, but also an update for port:mesa which removes the default +llvm40 variant. That's where the clang-4 dependency comes from.

Both should fix your issue, but if you don't already have many of the Mesa dependencies installed and don't care for that Plotter class you can now install kf5-kdeclarative and all frameworks that depend on it without having to build clang.

I'm still curious: why doesn't clang-4 build currently. Is that an issue with my version of the port, or is it a general issue?

Tatsh commented 5 years ago

I'm still curious: why doesn't clang-4 build currently. Is that an issue with my version of the port, or is it a general issue?

This is a general issue I guess that would have to be filed with the MacPorts bug tracker.

RJVB commented 5 years ago

OK, whew.

I'll be trying to upgrade my port:Mesa, so if you do have an interest in that keep an eye out for it.