new port: R-framework

[kjell.konis@…]

The R.framework port uses the llvm-gcc42 compilers, installs itself in ${prefix}/Library/Frameworks and supports all of the OSX/Aqua/Quartz goodness that has been added to R over the last several years. It also creates a link ${prefix}/bin/R so that it can be used a a drop-in replacement for the R port (however, this causes it to conflict with the R port).

I also updated the R port so that it knows about the conflict with R.framework.

I plan to keep the R port around for the *nix/X11 user interface and build it using the most up-to-date gcc (4.4 and eventually 4.6).

[kjell.konis@…]

R portfile revision. The patch is no longer used so the files directory can be removed.

[ryandesign (Ryan Carsten Schmidt)]

The new port should use dist_subdir R so the distfile doesn't need to be downloaded a second time for users or our mirror servers.

Do we have any other ports that have a period in their name? Does that even work?

[ryandesign (Ryan Carsten Schmidt)]

Does it really need to depend on port:llvm-gcc42? Would not the llvm-gcc-4.2 compiler built into Xcode on Snow Leopard and later suffice on those operating systems?

Is "license GPL-2 GPL-3" really correct, or would this be the same as saying "license GPL-2+" like we do in countless other ports?

[kjell.konis@…]

Replying to ryandesign@…:

Does it really need to depend on port:llvm-gcc42? Would not the llvm-gcc-4.2 compiler built into Xcode on Snow Leopard and later suffice on those operating systems?

AFAICT, macports-llvm-gcc-4.2 is the only set of compilers that includes fortran, C, C++, and ObjC and can link to the Frameworks in /System/Library. I would prefer to use the Xcode compilers but I don't know what to do for Fortran.

Is "license GPL-2 GPL-3" really correct, or would this be the same as saying "license GPL-2+" like we do in countless other ports?

From the latest R news:

The Licencing change to GPL-2 | GPL-3 may be of interest to some.

I wasn't sure if "GPL-2+" meant the same things as "GPL-2 | GPL-3" so I went with "GPL-2 GPL-3".

[kjell.konis@…]

Replying to ryandesign@…:

The new port should use dist_subdir R so the distfile doesn't need to be downloaded a second time for users or our mirror servers.

Good point. I update the attached Portfile.

Do we have any other ports that have a period in their name? Does that even work?

So far it's worked fine for me. Pretty soon I am going to submit a port for R.app so there would be at least 2 ports with a . in the name :) If you think it's better I can call them R-framework and R-app.

[kjell.konis@…]

Since the vast majority of ports with framework in the name are named something-framework I renamed this port R-framework. The updated Portfile is attached.

[kjell.konis@…]

I split the x11 variant into x11, cairo, and tcltk variants. New Portfile attached.

[kjell.konis@…]

New Portfile attached. Changes:

(1) The port doesn't use architecture dependent subdirectories for the libraries anymore since R.app is not able to link to R.framework when they are present (not a big deal because there is no universal variant).

(2) Portfile now uses ${frameworks_dir} instead of ${prefix}/Library/Frameworks.

(3) The new Portfile has a variant (symlink) controlling the 2 links that conflict with the R port. The changes to the R port in R-Portfile.diff are no longer necessary.

[kjell.konis@…]

The R-Portfile.diff (and it's comment) no longer apply. These changes are made to the R port in #31513. Also, I decided to keep the aqua variant around for Snow Leopard.

[ryandesign (Ryan Carsten Schmidt)]

Some comments:

• Is pkgconfig really a library dependency? Usually it's only needed at build time.
• The reinplace you're doing in a post-extract block should be in a post-patch block instead. You want to be able to "sudo port extract R-framework" and see the pristine extracted files. This change should be made to R as well.
• MacPorts adds the --prefix argument in configure.pre_args for you. If you want to change it, overwrite configure.pre_args instead of adding --prefix to configure.args.
• In the cairo variant, the cairo, pango and glib2 dependencies should be written such that cairo-devel, pango-devel and glib2-devel, respectively, could satisfy them as well. Consult other ports that depend on these ports for examples (including even your R port).
• In the post-destroot block, when you "xinstall ${destroot}${frameworks_dir}/lib/pkgconfig/libR.pc ${destroot}${prefix}/lib/pkgconfig", that will use the default permissions of 755, but pkgconfig .pc files do not need the execute bit, so you should specify -m 644 when you xinstall. Or even easier, why not just move the file, instead of copying it, then deleting it? You also don't need to manually delete empty directories; MacPorts will delete empty directories for you after destroot.
• The symbolic links you're creating with ln are pointing into the destroot, which you don't want.

[kjell.konis@…]

Updated Portfile to latest version of R

[kjell.konis@…]

I just attached an updated Portfile that (I hope) addresses all of these points. Thanks.

Replying to ryandesign@…:

Some comments:

• Is pkgconfig really a library dependency? Usually it's only needed at build time.
• The reinplace you're doing in a post-extract block should be in a post-patch block instead. You want to be able to "sudo port extract R-framework" and see the pristine extracted files. This change should be made to R as well.
• MacPorts adds the --prefix argument in configure.pre_args for you. If you want to change it, overwrite configure.pre_args instead of adding --prefix to configure.args.
• In the cairo variant, the cairo, pango and glib2 dependencies should be written such that cairo-devel, pango-devel and glib2-devel, respectively, could satisfy them as well. Consult other ports that depend on these ports for examples (including even your R port).
• In the post-destroot block, when you "xinstall ${destroot}${frameworks_dir}/lib/pkgconfig/libR.pc ${destroot}${prefix}/lib/pkgconfig", that will use the default permissions of 755, but pkgconfig .pc files do not need the execute bit, so you should specify -m 644 when you xinstall. Or even easier, why not just move the file, instead of copying it, then deleting it? You also don't need to manually delete empty directories; MacPorts will delete empty directories for you after destroot.
• The symbolic links you're creating with ln are pointing into the destroot, which you don't want.

[ryandesign (Ryan Carsten Schmidt)]

Added in r86855 along with my livecheck fix from #31910.