From owner-freebsd-ports@freebsd.org Tue Oct 4 06:38:01 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A82E7AF4F2E for ; Tue, 4 Oct 2016 06:38:01 +0000 (UTC) (envelope-from elferdo@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 86819AD4 for ; Tue, 4 Oct 2016 06:38:01 +0000 (UTC) (envelope-from elferdo@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 85DABAF4F2D; Tue, 4 Oct 2016 06:38:01 +0000 (UTC) Delivered-To: ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8579CAF4F2B for ; Tue, 4 Oct 2016 06:38:01 +0000 (UTC) (envelope-from elferdo@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4ECDAAD3; Tue, 4 Oct 2016 06:38:01 +0000 (UTC) (envelope-from elferdo@gmail.com) Received: by mail-io0-x231.google.com with SMTP id i202so63294046ioi.2; Mon, 03 Oct 2016 23:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pyaQFSUgYlx5+EuZ2GSbGtWTr6Xalmeas0WiyHL+49s=; b=cdMbEahJnf0Y5wzEXtAHvTry38O3Tqf9czKsqpiZ8WN4pYcziMpgW9dHM/o+Cv64Yf VxdwvWpzUh762uSGxlR8YnMlAELFy9JKfxD414WN0NEuSYQPC6TgLMnLww4np8/uXhVv ZEery/bLmPp9PaSeJkUNKtGoYFU47cfHyO7d9puDY55qEobwc7iEiy+mpI73K5KKMrCh cQw95ghZUTm+LHluGRQpnMACyjSkyLLRHT0GwhDbw22LSxqzdSmhZ985iTWGh9XD03kU 9m2UaRjOalPDEiOWrEeTTcndm/U4L9h+dEjgQbtaLEduo4SABGHcvT1dVKAMWTPTnKIz +0ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pyaQFSUgYlx5+EuZ2GSbGtWTr6Xalmeas0WiyHL+49s=; b=VQrEdSXiv0bxWFkZ8v/jhFGpExR3uvf0p0l/7xWIqUiCVI3QKIoF77vkFY1PDwCF/g a+KMFG8b5lvPBI8dUeoqLQ7iaS2Tx+F/uow1D23t4DrhnbpEmgTB9XUokqO30mTjrObf juhef6I8LMzjBJPZqXNaWhZRbRsfaNuUow+Jea0N5P+pScFpkqYAhE8wp42JU8MT42VL T+UQ/uLto8CFdB8Pu5rJroNMK7W3AuBXWDcxxY/mgD6Q0V0j5zX1C2GI8y/5Wf8IuwjV q3wwIuXY1pphnd8T7QcOO1IVo20jslQYk818kqoliHMYvCXAGOLslqXkvogh5PNxb5og Q8Pg== X-Gm-Message-State: AA6/9Rkh1LFF/0bKRfuFqyT+y78NQwjXKXd/pdtQ1b4UgFhuO5WzAIa9VWicAlba4SOivU27Z2ijuxGBprMQVA== X-Received: by 10.107.30.148 with SMTP id e142mr2635232ioe.82.1475563080615; Mon, 03 Oct 2016 23:38:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.95.18 with HTTP; Mon, 3 Oct 2016 23:37:58 -0700 (PDT) In-Reply-To: <864m4skef6.fsf@phe.ftfl.ca> References: <864m4skef6.fsf@phe.ftfl.ca> From: =?UTF-8?Q?Fernando_Herrero_Carr=C3=B3n?= Date: Tue, 4 Oct 2016 08:37:58 +0200 Message-ID: Subject: Re: math/R slave ports and shared library To: Joseph Mingrone Cc: ports@freebsd.org, Steve Wills , tota@freebsd.org, Dmitry Marakasov , thierry@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2016 06:38:01 -0000 2016-10-04 4:59 GMT+02:00 Joseph Mingrone : > After some surgery, math/R is in more manageable shape. But, the surgery > broke two slave ports, math/libR and math/libRmath. They have each been > marked broken since June or July and I posted to ports@ about deleting > them, but didn't get a response. > > This is great work indeed. The huge Makefile was a pain to work with, mainly because of the slave ports, so this is greatly appreciated. > math/libRmath > I'm not sure how widely used math/libRmath is today, but it's still > described in R's main installation document (https://cran.r-project.org/ > doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library). It > *should* be straightforward to just incorporate math/libRmath's four files > into math/R and then delete math/libRmath. The directory for libRmath is > under WRKSRC, but it's not included in the main Makefile, so I'd have to > either patch the main Makefile or do something with post-build and > post-install. Is this palatable? > > --- > post-build: > ${SETENV} ${MAKE_ENV} ${MAKE_CMD} -C ${WRKSRC}/src/nmath/standalone > > post-install > .for f in libRmath.a libRmath.so libRmath.so.${RMATH_SOVERSION} > ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/${f} > ${STAGEDIR}/lib/ > .endfor > ${INSTALL_DATA} ${WRKSRC}/src/nmath/standalone/Rmath.h > ${STAGEDIR}/include/ > --- > > I would be very surprised (though it cannot be excluded) to see C programs using libRmath. There are some questions on StackOverflow about developing and distributing libRmath, so this cannot be 100% excluded [2]. The de facto standard for R/C++ interoperability is Rcpp [1]. I am not sure whether Rcpp can be built standalone, but it being an R package, I suspect it needs a full R installation. Its main use is for R to include C++ code, no the other way around. 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++. math/libR > Right now, unlike upstream, math/R's shared library option is turned on by > default. This was done only in late June because a dependency, > math/rkward-kde4, required it. Upstream turns it off, for the reasons > described in [1]. I'm inclined to remove the libR option from math/R's > OPTIONS_DEFAULT and resurrect math/libR (or maybe math/R-libR by using > PKGNAMESUFFIX) as a very simple slave port that just installs math/R with > that option on. math/rkward-kde4 could then depend on math/libR. One > issue is that, I believe, R's installed packages (packages installed from > within R) and many of R's dependencies would have to be rebuilt after > turning off the libR option. > > 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. In my opinion, performancewise I would only leave LTO and OPENMP as default options. Even long double is not guaranteed to provide better precision than double and it is very possible (per theory and per experience) that it hinders performance [3]. Kind regards, Fernando [1] http://gallery.rcpp.org/articles/r-function-from-c++/ [2] http://stackoverflow.com/questions/5393257/including-r-standalone-library-in-a-c-source-tree [3] http://www.cplusplus.com/forum/beginner/34088/#msg183895