Fernando Herrero Carrón <elfe...@gmail.com> writes: > All in all, I don't see much use for a standalone libRmath, but it cannot > be excluded. The truth being told, I would expect newer scientific software > coming from python+scipy+numpy rather than from R embedded in C/C++.
Given that 1) the port has been marked broken for so long and 2) only you responded to the last call for deletion back in July with a similar response, I'm feeling more comfortable about removing math/libRmath. > math/libR > I have done some little benchmarking myself with and without dynamic libR > and have not seen any noticeable differences in performance (though I have > left it off to be safe), but don't take this as conclusive, more testing > should be done. Packages certainly do need to be rebuilt after switching > from dynamic libR to static. I can't tell what happens the other way > around. Ports-installed packages could be automatically recompiled, but > recompiling user-installed packages is a different story. > I think having two separate installations, whose packages would be mutually > exclusive is too dangerous and too easy for the user to mess up. I can > perform some more extensive benchmarks and see if having it enabled by > default really hurts. The same applies for math/libR. For now, users who don't want the shared library can easily build their own port. Thanks for your input Fernando, Joseph
signature.asc
Description: PGP signature
