Bug 210990
| Summary: | math/libRmath: Convert to standalone port, Mark Un'BROKEN | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Joseph Mingrone <jrm> | ||||
| Component: | Individual Port(s) | Assignee: | Joseph Mingrone <jrm> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | bf, imp, riggs, swills | ||||
| Priority: | --- | Keywords: | patch-ready | ||||
| Version: | Latest | Flags: | koobs:
merge-quarterly?
|
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210866 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210987 |
||||||
| Attachments: |
|
||||||
Just a general question: Is it necessary to have this port in the tree? There is no consumer in the ports tree, and I wonder: Are there many users who install this port but not math/R ? At this moment, math/R does not install files that math/libRmath does. Namely, lib/libRmath.a lib/libRmath.so lib/libRmath.so.%%RMATH_SOVERSION%%. This is a good question and it applies for math/libR as well. I am willing to move the features of math/libR and math/libRmath in to math/R. Maybe we should ask the old maintainer his thoughts and post on ports@? (In reply to Joseph Mingrone from comment #2) Good idea. If there is a good reason to keep these ports around, then we should. Can you go ahead and collect the information? I posted on ports@. I'll leave the question open for a week or two and summarize the feedback here. (In reply to Joseph Mingrone from comment #4) Any news? There haven't been any replies. I'm OK with math/libR being retired. My only hesitation is about performance. Here is an excerpt from the R Installation and Administration Manual. "Flag --enable-R-shlib causes the make process to build R as a dynamic (shared) library, typically called libR.so, and link the main R executable R.bin against that library. This can only be done if all the code (including system libraries) can be compiled into a dynamic library, *** and there may be a performance47 penalty. So you probably only want this if you will be using an application which embeds R. ***" I was considering turning the shared library off for math/R and having math/rkward-kde4, the only port that I'm aware of that depends on the shared library, depend on math/libR. The other implication for turning off the shared library, is that all R packages will need to be reinstalled. If we do turn off the shared library option, I'll clean up and simplify math/libR. Another argument is that those who want optimal performance can compile the port themselves. If we went back to a slave port, I think something as simple as this would work. ========== PORTNAME= R CATEGORIES= math lang PKGNAMESUFFIX= -libR MAINTAINER= jrm@ftfl.ca COMMENT= Shared library installation of math/R LICENSE= GPLv2 MASTERDIR= ${.CURDIR}/../../math/R OPTIONS_SLAVE= LIBR .include "${MASTERDIR}/Makefile" ========== Then math/R would just have to add something like this. LIBR_CONFLICTS= R-3.* LIBR_CONFLICTS_OFF= R-libR-3.* The R developers have this to say about the shared library performance hit. "We have measured 15-20% on i686 Linux and around 10% on x86_64 Linux." Is a slave port worth recovering this? Sorry for the barrage of emails. The title here is about math/libRmath, but the discussion switched to math/libR. In short, no one has replied regarding math/libRmath, so it's clear it can be removed from the tree. I'll wait for feedback regarding math/libR (math/R-libR). Reassign to submitter (with commit bit now :-) ) math/libRmath had a cleanup and math/libR has been removed. |
Created attachment 172360 [details] svn diff to fix math/libRmath ortlint: OK testport: OK (poudriere: 9.3-RELEASE-p36, i386, default options) testport: OK (poudriere: 9.3-RELEASE-p30, amd64, default options) testport: OK (poudriere: 10.3-RELEASE, i386, default options) testport: OK (poudriere: 10.3-RELEASE, amd64, default options)