Created attachment 172360 [details]
svn diff to fix math/libRmath
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)
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,
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)
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.
CATEGORIES= math lang
COMMENT= Shared library installation of math/R
Then math/R would just have to add something like this.
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.