On Aug 22, 2009, at 14:13, Jonas Bähr wrote:
Am 22.08.2009 um 18:03 schrieb Rainer Müller:
On 2009-08-22 17:57 , Ryan Schmidt wrote:
On Aug 22, 2009, at 06:43, [email protected] wrote:
+depends_lib port:R
+
+variant custom_r description {Use a custom R installation instead
depending on macports' R} {
+ depends_lib-delete port:R
+}
Why this? Is there a good reason why someone could not use the
MacPorts R and would need to install their own? MacPorts policy is
generally to use MacPorts versions of things only.
Especially if nothing else is changed, this would not find another
installation of R as MacPorts does not search outside of the
prefix. But
if R is not even required for building, this should be depends_run
instead.
R is needed to build and run. The install script looks for "R" in
PATH, that's all.
The rational behind the custom R is to lighten the dependencies for
the user. The R-Project provides very good customizable installer/
binaries for Mac OS X. MacPorts's R port however can't be
customized at all and pulls in a complete gcc plus xorg. In my eyes
it's much more convenient for a user who already uses R to continue
to use his installation and install rpy2 within 5 minutes instead
of spending 6 hours compiling xorg, gcc, and an other bunch of
dependencies for nothing. If the user's R comes in PATH before
macports R, it won't be used anyway.
MacPorts does not use your $PATH at build time. It uses the value of
binpath in macports.conf. So for this to work a user would at least
have to add the location of their binary installation of R to the
binpath, and maybe also to their runtime PATH.
The R port presumably requires a gcc port because it cannot be built
with the gcc Apple provides.
There are many many ports in MacPorts for software that needs xorg.
They will all cause various xorg ports to be installed. That is not a
reason not to use them.
It is not the MacPorts way to use a user's software that was not
installed with MacPorts. MacPorts is a package management system. It
is supposed to manage your packages. But it cannot do that if you
allow ports to use software that is outside of MacPorts.
It would be best to remove the custom_r variant and make the port
always use the MacPorts R port. If the R port does not provide all
the options a user of R would expect, please file tickets requesting
the R port be enhanced in whatever ways necessary.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
