On Apr 9, 2016, at 3:29 AM, René J.V. Bertin wrote: > The KF5 version of the KDevelop IDE uses libclang for its C/C++ parser, and > requires a clang installation that includes llvm-config. Apple doesn't > include that utility (and possibly other required components) in its > toolchain, so one needs a 3rd party clang installation. > > To be more exhaustive, this is the information requested: > ../lib/llvm-3.5/bin/llvm-config --version > ../lib/llvm-3.5/bin/llvm-config --includedir > ../lib/llvm-3.5/bin/llvm-config --libdir > ../lib/llvm-3.5/bin/llvm-config --cppflags > ../lib/llvm-3.5/bin/llvm-config --ldflags > ../lib/llvm-3.5/bin/llvm-config --libs core bitreader asmparser analysis > ../lib/llvm-3.5/bin/llvm-config --libfiles > ../lib/llvm-3.5/bin/llvm-config --prefix > ../lib/llvm-3.5/bin/llvm-config --src-root > > Port:kf5-kdevelop will thus propose different llvmXY variants that determine > which clang version is used for the parser. At the moment it also picks a > default if no variant is set explicitly, but I'm not really comfortable with > that (or the alternative, raising an error if no variant is set). > > It also turns out I had to blacklist at least the 10.9 Apple clang (602) > while apparently the current 3.5 clang release is supposed to build the code > without issues. > > Either way, there is thus at least one OS X version where it would stand to > reason to use the internal compiler version selection procedure to determine > the default clang version to use for the parser (default +llvmXY variant). > That way users can install the llvm/clang ports of choice, and don't have to > repeat that choice through explicit selection of an llvm variant for KDevelop > (and evidently for other ports that also depend on llvm or clang libraries). > It should also allow for more transparent upgrade paths. > > I would think that an adaptive mechanism to determine a default variant isn't > incompatible with reproducible builds (or at least an accepted/able > exception) because the selected variant will still build the same everywhere. > If so, is the definitive choice of compiler known sufficiently early to use > it for defining a default variant, and/or is there already something in place > to do this? I don't have access to my Mac right now so I cannot just check > for myself.
When multiple version variants are available, we usually suggest you default to the latest stable version. Right now that's llvm-3.7. _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
