lang/gcc42 without gfortran

[bf]

--- On Mon, 3/16/09, Rainer Hurling <rhurlin at gwdg.de> wrote:

> From: Rainer Hurling <rhurlin at gwdg.de>
> Subject: Re: lang/gcc42 without gfortran
> To: bf2006a at yahoo.com
> Cc: gerald at FreeBSD.org, "Mark Linimon" <linimon at lonesome.com>, freebsd-ports at FreeBSD.org
> Date: Monday, March 16, 2009, 5:48 AM
> Thank you for this information.
> 
> As far as I know I am one of only a few persons who are
> testing development versions of R on FreeBSD CURRENT. So
> most times I can not use the port math/R and instead I have
> to build R manually. This was very easy with FreeBSD as long
> as the fortran compiler was integrated in the base system.
> For some time now we have to install the gfortran compiler
> by lang/gcc4x. And here my problems with some third party
> software outside the ports system begun.
> 
> Compiling software like R normally uses the system compiler
> version, i.e.  gcc 4.2.1. So gfortran version 4.2.x is
> needed.
> 
> When I want to use version 4.3.x instead I explicitly have
> to set some vars in etc/make.conf:
> 
>   # Only for ports
>   .if ${.CURDIR:M*/ports/*} &&
> !${.CURDIR:M*/work/*}
>   # Set gcc version for ports.
>   CC=                     gcc43
>   CXX=                    g++43
>   CPP=                    cpp43
>   .endif
> 
> I tried it and it works. But there are some problems
> remaining with version 4.3.x that are not resolved for me at
> this time.
> 
> First of all, building and installing the system (world and
> kernel) furthermore needs the system compiler (version
> 4.2.1). In the ports system there are some ports that do not
> build with gcc 4.3.x, for example multimedia/miro or
> x11/nvidia-driver.
> 
> Because of problems like that I often have to juggle with
> env settings for the compiler version depending on that part
> of software I just want to build.
> 
> Is there any elegant possibility to use gcc version 4.3.x
> for third party software outside the ports system, but for
> all other cases using the system compiler (version 4.2.1)
> without juggling env vars in etc/make.conf or any other
> place?
> 
> For me it seams the best and easiest solution would be to
> use gfortran in version 4.2.x until the system compiler
> itself will be changed towards version 4.3.x. (It is fiddly
> always to patch lang/gcc42 for gfortran...)
> 
> Rainer

Well, elegance is subjective. ;)  

I don't see your problem.  In gcc 4.3.x you have a good compiler
suite that you can use, and you have a seemingly adequate means
of defining the compilers via make.conf (you have to do that
anyway for gfortran42, don't you?).

The base system isn't affected by your port-specific additions
to make.conf, and the few ports that don't compile properly
under 4.3.x can be set off by something like:

.if ${.CURDIR:M*/ports/multimedia/miro*}
CC=                     cc
CXX=                    c++
CPP=                    cpp
.endif

You can also add your development version of R to ports by
writing a port to put in your local tree, which might be more
convenient in the long run.  So what's your worry?  I can think
of a few alternatives, like including some Makefile with
alternative definitions in some builds, or defining compilers on
the command-line via env(1) or make -e, or sym-linking
commonly-used compiler names to a specific compiler.  There is
also a more powerful approach via the sysutils/penv port.  But
you don't seem to need any of these.  To my mind, the only
reasons for adding gfortran42 would be if:

-- you have found an important regression in gfortran43, and
it is unlikely that it will be fixed soon;

-- you have a port that compiles under gfortran42 and not
gfortran43 which is difficult to patch;

-- you have a binary-only package which links against gfortran42
libraries;

or

-- you want to build binaries with gfortran42 for the sake of
comparison with binaries built with other compilers.

But none of these seem to apply here.  

Some people would like to change the system compiler to 4.3.x,
but it doesn't seem likely to happen soon, because there is
a lot of resistance to GPLv3-licensed code in the base system.

Regards,
         b.