R 2.5.0: use gcc42

[ryandesign (Ryan Carsten Schmidt)]

I don't use R; I'm looking through all ports that depend on gcc40 trying to determine if they could be updated to use the latest stable version of gcc, which is gcc42. In fact, R already uses gcc42, but only on Intel processors. Is there any reason why it should not be updated to use gcc42 all the time? If not, the port should be updated to always use gcc42. It would be very unfortunate for someone to have to build both gcc40 to build R and gcc42 to build some other port, especially since that requirement would only hit those in the worst shape for building huge packages like gcc -- those with PowerPC Macs, which on average have less RAM, less hard drive space, and are much slower at these kinds of things than Intel Macs.

Patch attached to update R to always use gcc42. Note that I have not tested this patch, because I would not know how to test the resulting R to ensure that it worked properly. But if someone would test it and tell me it works, I would be happy to commit it.

[konis@…]

I have been thinking of changing the gcc dependency to gcc42. The only thing that's stopped me is that the R port has used gcc40 on ppc for a while now so I figured most of the people using the R port would already have gcc40 installed. If I were to change it to gcc42 the next time anyone upgraded it would take like a day since they would need to install gcc42 first.

[ryandesign (Ryan Carsten Schmidt)]

Admittedly I made the same arguments about the pdftk port, back when I had a PowerPC machine. Now I can make grand statements about the rightness of things from the high ground of my MacBook Pro, knowing that it won't be me that has to spend 8 hours rebuilding gcc.

However, I persist. We must move MacPorts forward. We must keep ports up to date. gcc40 was probably chosen for R because gcc41 was probably in beta at the time, and you don't want to depend on beta software. But now gcc42 is out of beta. So it is the right choice. Existing users are a consideration, sure, but we must also consider all new users, for whom it would, as I stated originally, be unfortunate to have to install multiple compilers, just because one port hadn't updated to the latest gcc. (I realize there's more than one port that still depends on gcc40. I'm filing bugs on all of them.)

The solution implemented in pdftk at the time, and one which I have continued since becoming maintainer, is allowing the user to choose the compiler with variants. See the pdftk portfile​. For example, you could offer the choice of gcc40 or gcc42, with gcc42 being the default if neither is specified. But even if you add that to R now, it won't help users who have it installed already. When they upgrade, since they don't currently have one of those variants selected, MacPorts would select gcc42.

There may be a way to set the variant based on which gcc port is already installed. That would be a fair compromise. I'm just not sure of the syntax, nor which port to look at for an example of that. But I think I've seen it done somewhere. Maybe ask the -dev list if you can't figure it out.

[konis@…]

Okay, I like the choosing the compiler with variants solution. Give me a couple of days to make sure both variants work on ppc (sorry, first gen mini). I'll make +gcc40 conflict with i386 so nothing will really change for intel users.

[konis@…]

port file for R 2.5.1

[konis@…]

R just got bumped to 2.5.1 so I thought I would use this opportunity to change the gcc dependency to 4.2. I decided not to bother with making a with_gcc40 variant. The R 2.5.1 Portfile also removes the platform darwin 6 variant since MacPorts doesn't officially support OS X 10.2 and since I have no way to test it.

[gwright@…]

Committed Kjell's update to 2.5.1 and gcc42 as r26915. Thanks!

[(none)]

Milestone Port Enhancements deleted