On Wednesday May 04 2016 08:25:09 Ryan Schmidt wrote: > I looked at the version number of the llvm-3.7 port and noted it was 3.7.1, > which looks like a stable version number. > I looked at the version number of the llvm-3.8 port and noted it was > 3.8-r262722_1, which looks like a development version number.
Indeed... > I concur, that's how Jeremy has historically handled it. And in r146341 he > turned it off for llvm-3.8, noting that he did so because it is now a stable > release. So I guess llvm-3.8 is already considered stable. That is certainly the impression I have. Maybe he chose to use a snapshot somewhere between 3.8.0 and 3.8.1, containing patches he'd otherwise have to ship with the port? > > Either way, I don't think the compiler selection mechanism itself follows > > this guideline. If it hasn't been updated in svn I presume it still takes > > the first (lowest) version that passes the selection criteria? > > To which compiler selection mechanism are you referring? Sorry, the one that's governed by black- and whitelisting. If for some reason a user has llvm-3.6 and llvm-3.8 installed and both are acceptable, that mechanism will select clang-3.6 for building. That's not the choice one would make, usually. > I guess I really don't understand what issue you're trying to work around or > why. I don't see why the existing methods we've used to handle this > situation, as I've described, aren't satisfactory to you. The main point here is that clang+llvm isn't a trivial dependency, while the component that is being depended on is only a tiny part of that. It's also a very well preserved library, with an ABI that hasn't changed since 3.5 . That doesn't mean there are no improvements "behind the scenes" of course, but those improvements could be provided by simply replacing just libclang.dylib . The way things work currently, (future) users of a KDevelop port who want to use the binary package will find themselves pulling in a new clang+llvm periodically, which is installed in addition to (rather than instead of) the versions they already have installed. Overkill, disk waste, reasons enough why I don't find it satisfactory. The fact that you have to select an llvm variant while (at least on 10.9) a clang port is required in order to build the port isn't very satisfactory either. It's very tempting to make the port set the build compiler to the version selected through the +llvm variant. With my split of the KDevelop port the clang/llvm dependency is moved to a rather tiny port, but ideally there would be a libclang port that provides just that library and its headerfiles (with variants for all llvm versions that are not the latest stable release). R _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
