On Sun, Mar 15 2020, Klemens Nanni <k...@openbsd.org> wrote: > All subpackages ave a RDEP on python, so explicitness for -python is > redundant.
-python ships a true python module, IMO it should have an rdep on python like other python modules in the tree. Same goes for -lldb. -main ships a bunch of python scripts, but right now those scripts aren't properly MODPY_ADJ'd. I think it makes more sense to discuss removing the python rdep in this subpackage. scan-view for example is a python script, thankfully scan-build alone is enough. > More importantly, this uncovers how the devel/gtest RDEP has been > clobbered by it; The deps of the -python subpackage make sense to me as-is, without an explicit dependency on devel/gtest. > I cannot yet say what inside LLVM actually requires > gtest(1) at runtime and the dependency was added in 2017 for the 4.0.1 > update, but we can fix this in a different commit. Actually gtest was added in Makefile rev 1.71 for an llvm 3.5 snapshot, the two lines below were added to pkg/PLIST for llvm 3.0 and are now outdated. I'll do a few more tests but I'm about to delete the gtest rdep, the installed files only reference gtest in three places which don't seem relevant. Brad, do you know if gtest is still useful in RUN_DEPENDS? Index: pkg/PLIST-main =================================================================== RCS file: /cvs/ports/devel/llvm/pkg/PLIST-main,v retrieving revision 1.16 diff -u -p -r1.16 PLIST-main --- pkg/PLIST-main 6 Mar 2020 14:39:57 -0000 1.16 +++ pkg/PLIST-main 16 Mar 2020 00:50:52 -0000 @@ -2455,8 +2455,6 @@ lib/cmake/llvm/VersionFromVCS.cmake @static-lib lib/libclangStaticAnalyzerCore.a @static-lib lib/libclangStaticAnalyzerFrontend.a @static-lib lib/libclangTooling.a -@comment lib/libgtest.a -@comment lib/libgtest_main.a @static-lib lib/libclangToolingASTDiff.a @static-lib lib/libclangToolingCore.a @static-lib lib/libclangToolingInclusions.a > Eventually, I want to use Python 3 inside LLVM - this diff is a first > step, but it already showed side effects, so let's go one by one. > > > Feedback? OK? Not ok with this diff, but I'm happy with moving llvm to python3 if possible. I took a look some days/weeks ago, sadly I didn't note down why the switch wasn't straightforward. Maybe I was just busy with something else. Looks like a bunch of python files import __future__ so this looks promising. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
