Created attachment 238018 [details] Patches and port description for new science/root port Hello! I have managed to make the latest stable version of CERN's ROOT framework (https://root.cern/) used in high energy physics and similar fields compile on FreeBSD 13.1-Release. Currently, I have only managed to compile ROOT on amd64 architecture, but I see no reason why it should not compile on newer versions of FreeBSD, and even slightly older. My work would have to be uploaded as an entirely new port (I see that, ages ago, there was a port of ROOT which has since been removed). I am finding it a bit difficult, however, to carry out the necessary tests on my end - inside and outside of poudriere - so I attach here an archive containing 1) the patches necessary to make ROOT compile in the directory 'patches'; and 2) the Makefile and pkg-* files of the port in the directory 'root'. The patches are to be applied to the git repository available at https://github.com/root-project/root on the tag 'v6-26-06' - this information is contained in the Makefile as well. The structure of the patches archive is the same as that of the source repository, where the files contained in the patches archive are meant to replace the files of the same names in the source repository. Please let me know what I can do from here to prepare the port for submission. Cheers from Erik
I should perhaps clarify that ROOT not only compiles, but actually runs with graphics, I/O, python bindings etc.
(In reply to Erik Jensen from comment #1) Hello, Erik! :-) I took a look at your work, and it looks like you mostly just need to manage your "patches" correctly. The easiest way to accomplish this will be to clone the cern.root peoject to a location you can work in. You, having already creating the desired outcome for the diff files (patches) will for every file you've changed, rename the original with a .orig extension. eg; cp build/unix/compiledata.sh build/unix/compiledata.sh.orig then copy your modified version over the original. eg; cp ../patches/build/unix/compiledata.sh build/unix/ When you've completed this process. You can then run diff(1) over all the affected files. eg; diff -u build/unix/compiledata.sh.orig build/unix/compiledata.sh > ../files/build_unix_compiledata.sh.diff Your final port should have a structure as such: science/root/ Makefile pkg-descr pkg-message pkg-plist which you already have. But you will also need to create distinfo Your completed patches will need to go in: science/root/files/ like above; build_unix_compiledata.sh.diff Underscores are used to denote directory separators. Make all your patches from the base of the source tree. When you've finished with all this. You'll be able to create a shar archive containing your new port. If any of this is unclear to you, feel free to email me. I'll be happy to help. --Chris
Remark: the proposed port resurrects devel/root: see https://www.freshports.org/devel/root And also: $ grep /root\| /usr/ports/MOVED devel/root||2011-02-21|Has expired: Port does not build on supported versions of FreeBSD
(In reply to Thierry Thomas from comment #3) Thanks for the heads-up. Good catch!
Erik, the title of this pr(1) should probably be changed to: Resurrect devel/root Thanks.
Comment #1, comment #5 - thank you very much for your helpful replies, Chris! I have changed the title of the port. Do you prefer to keep the port in the “devel” category? I personally think it would fit a bit better in the “science” category, but my opinions in this regard are neither super strong nor pulling on much more than a few months of experience with FreeBSD ports. I can also see a couple of arguments against naming the port the (in my opinion, very poorly chosen) name of the software “root”, but this is what the original authors have decided upon, so I initially chose this name for the port. The official GitHub project has this name for the code repository as well. Do you, anyway, think a port name such as “cernroot” would be better, so as not to confuse the port for a sysadmin account and similar? I think I have managed to prepare the port. I have been running a testport on my specifications in a poudriere jail, but compiling gcc11 (a prerequisite for some of the python dependencies, I believe; ROOT itself is compiled with llvm/clang) on my current limited capacity system hit the default timeout of 24 hours! I see in the documentation that there are several ways to get around this. Anyway, in not too long I’m hoping to be able to upload the port here. Thanks again
I have no opinion on the ports name, nor it's category. Except to say; from experience, you'll probably find it faster && easier to simply pull it back in as it was. Then rename (as|if) desired in the future. :-) Speaking of things; you'll now also be including: /usr/ports/MOVED into the list of things that need to be dealt with. a git style diff should be used. HTH --Chris
(In reply to Chris Hutchinson from comment #7) Are the steps involved in this to pull in the old port to a new directory (e.g. the old devel/root), override with my new port specifications and then to follow example 1 in chapter 3 of the Porter’s Handbook (https://docs.freebsd.org/en/books/porters-handbook/quick-porting/)? Including git-remove’ing any files from the old port which are not needed anymore?
(In reply to Erik Jensen from comment #8) To be clear; I hate git. That said; I find it easiest to 1) git the ports version just prior to it's removal. 2) Hack, hack, hack. 3) git (delete|add) as required. from /usr/ports/ perform: 4) git diff --staged> ~/port-category_port-name01.diff attach said diff(1) to this pr(1) along with the diff of the now modified: /usr/ports/MOVED file. Done! :-) HTH --Chris
Created attachment 238684 [details] git diff of resurrected port
Created attachment 238685 [details] diff -u of MOVED
Hi Chris, I finally found some time to finish the job. I have attached a git diff of freebsd-ports at commit a3abb0daa65f7f6d8d3eab385fd377edf8a43ef3 relative to my changes. I have also attached a diff of MOVED, resurrecting devel/root. In the process, it became necessary to propose a new port, math/vdt, which I have submitted here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268292 The port has passed a `poudriere testport` on the 2022Q4 branch (preferring pkg packages over building the dependent ports) on my end. Let me know if there is anything I have missed! Cheers from Erik
A *visual* examination of the resurrection patch looks good. But you should have pulled a copy of MOVED from the most recent commit available at the time of your work. Then, after hacking it, perform a: $ cd <ports-dir> $ git diff --staged >../MOVED.diff It appears you simply performed a diff -u HTH --Chris
Created attachment 238706 [details] git diff --staged of MOVED at most recent commit ac4d327
Right, I see :-) I have obsoleted my `diff -u` of MOVED and attached a new `git diff --staged` of MOVED at the most recent commit ac4d327. Thanks, Erik
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=acfc52ae2cea4108d8b45034ae0146e8d4a03f0f commit acfc52ae2cea4108d8b45034ae0146e8d4a03f0f Author: Erik Jensen <erik@tenku.dk> AuthorDate: 2022-12-26 08:13:22 +0000 Commit: Nuno Teixeira <eduardo@FreeBSD.org> CommitDate: 2022-12-26 08:16:37 +0000 math/vdt: New port: Fast and inline implementations of mathematical functions vectorised math: - A collection of fast and inline implementations of mathematical functions. - The functions can be used in autovectorised loops. - Double and single precision implementations are available. - No overhead present, no intrinsics used. - A scalar (T(T)) and array signature (void(const unsigned int,T*,T*)) are provided. Born and developed at CERN, it is used, among the others, by LHC experiments and the Geant4 simulation toolkit. Much of the VDT code is inspired by the well known Cephes mathematical library. WWW: https://github.com/dpiparo/vdt PR: 267717, 268292 math/Makefile | 1 + math/vdt/Makefile (new) | 19 +++++++++++++++++++ math/vdt/distinfo (new) | 3 +++ math/vdt/pkg-descr (new) | 13 +++++++++++++ math/vdt/pkg-plist (new) | 16 ++++++++++++++++ 5 files changed, 52 insertions(+)
From `git log -- devel/root` what commit hash did you choose to revert? Also, upload a shar archive of devel/root just in case. Thanks
(In reply to Nuno Teixeira from comment #17) For the diff between the old devel/root port and my new submission, I checked out commit with hash a3abb0daa65f7f6d8d3eab385fd377edf8a43ef3, which is the very last commit containing devel/root -- in the subsequent commit with hash 74a1fea448afef47f7da88ef8f4ce6ebf5972af8 devel/root is removed. Attaching shar archive of devel/root below this comment.
Created attachment 239034 [details] shar archive of resurrected devel/root
(In reply to Erik Jensen from comment #18) --- commit 74a1fea448afef47f7da88ef8f4ce6ebf5972af8 Author: Rene Ladan <rene@FreeBSD.org> Date: Mon Feb 21 22:17:16 2011 +0000 Remove expired ports: 2011-02-20 devel/root: Port does not build on supported versions of FreeBSD 2011-02-20 net/ztelnet: unfetchable / Does not compile with GCC 4.2 2011-02-20 print/kaspaliste: Does not compile with GCC 4.2 2011-02-20 sysutils/perf: Does not build on supported versions of FreeBSD commit 1b78ff3c003a1e36de7bb89541e1cbf3f5ebf9f3 Author: Tilman Keskinoz <arved@FreeBSD.org> Date: Thu Jan 20 10:49:37 2011 +0000 Mark DEPRECATED and set an EXPIRATION_DATE. Port does not build on supported versions of FreeBSD Feature safe: yes --- Didn't found a3abb0daa65f7f6d8d3eab385fd377edf8a43ef3 in log. Maybe 1b78ff3c003a1e36de7bb89541e1cbf3f5ebf9f3 is the right one before deleted. But it will not be a problem since you uploaded a shar. Thanks
Created attachment 239071 [details] 6.26.10 v0 - switch to release tarball 6.26.10 / MASTER_SITES (this way we avoid using USE_GITHUB and auto-generated tarbals - start moving _DEPENDS to USES when applicable - deleted pkg-message as it contains details of build warnings - not using LDCONFIG as poudriere not complaining about it - fixed pkg-plist with macro variables - added DOCS section - looking for variable substitution on pkg-plist libraries: lib/root/xxx.so.6.26 lib/root/xxx.so.6.26.10 with something like DISTVERSION:R / DISTVERSION to easier future updates - "CMAKE_ON= gnuinstall soversion", can't see any reference in CMakeLists.txt about "soversion" - build fails without: --- CONFIGURE_WRKSRC?= ${WRKDIR}/.build STAGEDIR?= ${WRKDIR}/stage CMAKE_ARGS+= -DSTAGEDIR=${STAGEDIR} MAKE_ENV+= ROOTSYS=${CONFIGURE_WRKSRC} --- Could you apply this diff on a clean tree (without devel/root) and do a test run? If you need to change something just do a `git add .` inside devel/root and upload it with `git diff --staged . > root.diff` and identify it with v1, v2, v3 with a brief summary of changes. Cheers
Created attachment 239084 [details] 6.26.06 v1 Did a successful test run on the attached patch which has a few additional modifications: - switch to release tarball from main site (no github url) - sticking to version 6.26.06 for now, will merge changes in version 6.26.10 into port once the current version is part of the ports tree - CMake flag "soversion" is defined in cmake/modules/RootBuildOptions.cmake and utilised in various other .cmake files - removed from Makefile, as they are not needed anymore: --- STAGEDIR?= ${WRKDIR}/stage CMAKE_ARGS+= -DSTAGEDIR=${STAGEDIR} --- - I will look into variable substitution of soversions in pkg-plist when I upgrade to version 6.26.10
(In reply to Erik Jensen from comment #22) Ok. Did finish testing successfully: Makefile: --- PLIST_SUB+= SHLIB_VER="${DISTVERSION}" \ SHLIB_SHVER="${DISTVERSION:R}" --- pkg-plist: lib/root/XXX.so lib/root/XXX.so.%%SHLIB_SHVER%% lib/root/XXX.so.%%SHLIB_VER%% Used SHLIB_{SH}VER as it is used widely on ports. Just need to check _DEPENDS that could be moved to USES and we good to go.
_DEPENDS: 1. do this port needs git as build dependency? 2. libxcb-icccm.so:x11/xcb-util-wm libxcb-util.so:x11/xcb-util Could be moved to USE_XORG= xcb 3. libxml2.so:textproc/libxml2 Could be moved to USE_GNOME= libxml2
Created attachment 239086 [details] 6.26.06 v2 Changes: - remove git as a build dependency (this was a leftover from fetching vdt with ALLOW_NETWORKING_PACKAGES in `poudriere testport`) - remove lib dependencies libxcb-icccm.so:x11/xcb-util-wm, libxcb-util.so:x11/xcb-util; add USE_XORG= xcb - remove lib dependency libxml2.so:textproc/libxml2; add USE_GNOME= libxml2
(In reply to Nuno Teixeira from comment #23) I missed this comment. Seems like you have already made these changes on your side. Let me know if there is anything else I can do.
Created attachment 239087 [details] 6.26.06 v2 - libxcb-icccm.so:x11/xcb-util-wm libxcb-util.so:x11/xcb-util moved to USE_XORG= xcb - libxml2.so:textproc/libxml2 moved to USE_GNOME= libxml2 - added SHLIB_{SH}VER PLIST_SUB
(In reply to Nuno Teixeira from comment #27) Git can also be removed as a build dependency
Created attachment 239089 [details] 6.26.06 v3 - remove git build dependency testport results: 124amd64: OK 131amd64: OK 140amd64: plist issues: --- ====> Running Q/A tests (stage-qa) ====> Checking for pkg-plist issues (check-plist) ===> Parsing plist ===> Checking for items in STAGEDIR missing from pkg-plist ===> Checking for items in pkg-plist which are not in STAGEDIR Error: Missing: lib/root/std_config.pcm ===> Error: Plist issues found. --- I've uploaded logs to https://people.freebsd.org/~eduardo/logs/root/v3/ and on 14 it doesn't install "std_config.pcm" file. Any clue of why this happens? Just in case I will do parallel tests using this diff on 6.26.10 version to have some comparison.
(In reply to Nuno Teixeira from comment #29) It might be due to the usage of different C++ standards on the different releases of FreeBSD? Is there any indication of this in the CMake configuration messages? CMake sets ROOT up for compilation with C++14 automatically on my own poudriere jail which runs 13.1R. Currently, ROOT is undergoing a transition from requiring C++11 as a minimum to requiring C++14 as a minimum and recommending C++17. In the longer term, ROOT should always be compiled against C++17. Perhaps, for now, as I made and tested the port against C++14, we can specify C++14 as a standard in the port's Makefile? If this is the reason, that is.
I see now from the logs that 12.4, 13.1 and 14.0 all use C++14 for compilation. All CMake builds even have the same number of build steps - this does not make it less strange… A major difference between 12.4 and 13.1 vs 14.0 is that the builds of the first two use Clang 13 whereas the the build of the latter uses Clang 14. I suspect the reason is hidden here somewhere.
(In reply to Erik Jensen from comment #30) Yes, I was writing this at same time: --- -std=c++14 is set auto on 140, 131 and 124 with clang 14.0.5 on 140 and 13.0.0 on 131 and 124 as we can see at https://people.freebsd.org/~eduardo/logs/root/v3/ (using -DCMAKE_CXX_STANDARD=17 will automatically enable ROOT7 still experimental, so best bet is using 14 as ROOT7 will build more things) So this behaviour could be due to different compiler versions not standards. What should we do? - forcing same clang version to be used in different bsd versions with USES= llvm:13 could be excessive since we don't getting build problems - using an exception with an if condition to add/remove "std_config.pcm" file from plist?(In reply to Erik Jensen from comment #31) ---
Have you tried USES+= compiler:c++14-lang and maybe USE_CXXSTD= c++14
(In reply to Erik Jensen from comment #31) I will check latest version to see if same happens. This could be some kind of bug but it's hard to know as we are shooting in the dark because the lack of meaning of what is that file.
(In reply to Thierry Thomas from comment #33) testing with USES= compiler:c++14-lang CMAKE_ARGS= -DCMAKE_CXX_STANDARD=14
(In reply to Nuno Teixeira from comment #35) Same result on 140, file isn't installed.
From CMakeLists.txt: --- # FIXME: move installation of PCMS in ROOT_GENERATE_DICTIONARY(). # We are excluding directories, which are accidentaly copied via unxpected behaviour of install(DIRECTORY ..) install( DIRECTORY ${CMAKE_BINARY_DIR}/lib/ DESTINATION ${CMAKE_INSTALL_LIBDIR} FILES_MATCHING PATTERN "*.pcm" PATTERN "modules.idx" PATTERN "JupyROOT" EXCLUDE PATTERN "JsMVA" EXCLUDE PATTERN "python*" EXCLUDE PATTERN "cmake" EXCLUDE PATTERN "pkgconfig" EXCLUDE ) --- I liked "unxpected behaviour" in that :) Testing 6.26.10, tomorrow I will have results. I'm using a 131 jail to compile and produce a plist and after I will test 140.
(In reply to Nuno Teixeira from comment #37) Aha, at least this might give a way of controlling the inclusion of our one offender - nice find! I have looked through the ROOT source code and cannot find any reference to "std_config.pcm" nor to "std.pcm" which are both placed in the "lib" subdir of the build directory. I did, however, find, in /usr/src/contrib/llvm-project/libcxx/include on FreeBSD 13.1 (i.e. LLVM/Clang 13.0.0), the file module.modulemap which defines the modules "std_config" and "std". The way these are defined in LLVM/Clang 13.0.0 seem subtly different from the corresponding definitions in the source code of LLVM/Clang 14.0.5 which FreeBSD 14.0 uses. So, the different major versions of LLVM/Clang produce a varying number of .pcm files, which, in either case, are linked into the .pcm files defined in ROOT - e.g. "Core.pcm", "MathCore.pcm", etc. Maybe this is not so bad? Would it perhaps be an acceptable solution to conditionally populate pkg-plist with/without "std_config.pcm" depending on the version of LLVM/Clang? Initially, we could assume that any version of LLVM/Clang >= 14 does not produce the file "std_config.pcm"?
Also, I completely agree - let us stick to C++14 for now. I'm adding compilation against C++17, which implies inclusion of experimental ROOT version 7 code, to my todo list (which can be found at https://github.com/eamjensen/root-fbsd, by the way). Some of the experimental features have already been reported to be out of development, and some users (myself included) would also appreciate the availability of these :-)
(In reply to Erik Jensen from comment #38) I was thinking on the same but it would be a ugly fix without knowing what's the cause. Now that you found that its related, de facto, with clang version, then we can fix it that way until a better solution is found. I was thinking something like: --- .if ${OSVERSION} < 1400000 PLIST_FILES+= lib/root/std_config.pcm --- This way we can get problems if someone changes it's default clang, but it's a start. I will test it.
(In reply to Erik Jensen from comment #39) I'm not familiar with this software but you can add it to port with options: CMAKE_ARGS= -Droot7=ON/OFF OPTIONS_DEFINE= ROOT7 ROOT7_CMAKE_BOOL= root7 And this way users can test new features
(In reply to Nuno Teixeira from comment #41) (...) It will be a good training hacking plist :)
Created attachment 239109 [details] 6.26.06 v4 - Use CXX_STANDARD=14 (17 will enable root7 features) - Add simple hack to handle file not installed on 14 Current (clang 14+) Testport: {140,131,124}amd64: OK 124i386: depends fails to build
(In reply to Nuno Teixeira from comment #42) I'll take the challenge :-) (In reply to Nuno Teixeira from comment #43) Nice that the port now passes on all three amd64 builds. It was a bit of an effort to communicate to ROOT's CMake specifications that I was on an amd64 architecture on FreeBSD, such that it would compile on my machine, when I started hacking the source code. This is why I put amd64 as the only currently working type of architecture. I intended to expand into e.g. arm64 further down the line, and I can have a look at i386 as well, eventually.
(In reply to Erik Jensen from comment #44) Nice. This PR is ready to land. Please let me know when I should commit it. Cheers
(In reply to Nuno Teixeira from comment #45) Please, go ahead :-) Thanks again!
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=3ad0e6474b2c2beccdd55a58802381701fa10d34 commit 3ad0e6474b2c2beccdd55a58802381701fa10d34 Author: Erik Jensen <erik@tenku.dk> AuthorDate: 2022-12-30 10:42:00 +0000 Commit: Nuno Teixeira <eduardo@FreeBSD.org> CommitDate: 2022-12-30 10:44:41 +0000 devel/root: Revive port: Data analysis framework made at CERN - Submitter becomes maintainer ROOT is a framework for data processing, born at CERN, at the heart of the research on high-energy physics. Every day, thousands of physicists use ROOT applications to analyze their data or to perform simulations. WWW: https://root.cern/ PR: 267717 MOVED | 1 - devel/Makefile | 1 + devel/root/Makefile (new) | 66 + devel/root/distinfo (new) | 3 + .../files/patch-build_unix_compiledata.sh (new) | 11 + .../patch-cmake_modules_CheckCompiler.cmake (new) | 11 + .../patch-cmake_modules_SetUpLinux.cmake (new) | 22 + .../root/files/patch-core_base_src_TUUID.cxx (new) | 12 + ...atch-core_dictgen_src_rootcling__impl.cxx (new) | 11 + .../patch-core_metacling_src_TCling.cxx (new) | 20 + ...ch-core_metacling_src_rootclingTCling.cxx (new) | 14 + .../patch-core_thread_src_TPosixThread.cxx (new) | 11 + .../patch-core_unix_src_TUnixSystem.cxx (new) | 11 + ...preter_cling_include_cling_libc.modulemap (new) | 9 + devel/root/files/patch-main_CMakeLists.txt (new) | 13 + devel/root/pkg-descr (new) | 23 + devel/root/pkg-plist (new) | 5521 ++++++++++++++++++++ 17 files changed, 5759 insertions(+), 1 deletion(-)
Committed, thanks!