svn commit: r452962 - head/math/libRmath

[Joseph Mingrone]

Tijl Coosemans <tijl at FreeBSD.org> writes:

> On Fri, 27 Oct 2017 12:17:41 -0300 Joseph Mingrone <jrm at FreeBSD.org> wrote:
>> Tijl Coosemans <tijl at FreeBSD.org> writes:
>>> I don't see this approach to support flang work.  Will this have to be
>>> added to all Fortran ports?  Will you modify all Fortran ports whenever
>>> flang supports a new architecture?  Will users run into problems when
>>> they select gfortran in some ports and flang in others?  Will you allow
>>> port maintainers to set different defaults in their ports?  It all looks
>>> like high maintenance and highly error prone.  Too many modifiable
>>> variables in too many places.  

>>> USES arguments are the wrong mechanism for this in my opinion.
>>> DEFAULT_VERSIONS seems much better to me.  Users can then add
>>> fortran=gfortran or fortran=flang to DEFAULT_VERSIONS.  fortran.mk would
>>> look at FORTRAN_DEFAULT to determine the fortran compiler instead of
>>> fortran_ARGS.  All ports would simply have USES=fortran and no options.
>>> That's two variables in two locations: the user's DEFAULT_VERSIONS in
>>> make.conf and the ports tree FORTRAN_DEFAULT in bsd.default-versions.mk
>>> (which could eventually be set to flang on amd64 if that turns out to be
>>> a better default).  Advanced users that want to build some ports with
>>> flang and some with gfortran and think they know what they're doing can
>>> figure out the if-elseif-else logic needed in their make.conf.  Port
>>> maintainers/committers should not have to deal with the support requests
>>> resulting from such mixed configurations which is very likely if you
>>> add per port options like you do in this commit.  

>> The DEFAULT_VERSIONS solution is cleaner, but switching all Fortran
>> ports to build with flang would cause breakage and, as you know, flang
>> is currently only available for amd64.  The current, more complicated,
>> fine-tuned approach is less drastic.  If port maintainers do not make
>> any changes, nothing with their port changes.  They have time to test
>> with flang and make a choice to opt in.  For example, math/R defaults to
>> flang (on amd64) because we have problems with gfortran [1][2] and a
>> work-in-progress port for Rstudio [3] only works when math/R uses flang.
>> Hopefully flang will mature and become supported on more architectures,
>> port maintainers will put in some work to support flang, and it will be
>> an obvious choice to move to the DEFAULT_VERSIONS approach.  This is not
>> a precedent for choosing the compiler as a port option [4].

>> [1] https://wiki.freebsd.org/libgcc%20problem
>> [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220359
>> [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221127
>> [4] E.G. cad/ghdl games/eduke32 lang/erlang-runtime16 lang/gambit-c
>>     math/opensolaris-libm multimedia/x264 net-p2p/cpuminer net/asterisk11
>>     www/mod_spdy

> The download problem you have in math/R looks like the problem reported at
> https://lists.freebsd.org/pipermail/freebsd-current/2017-August/066855.html
> https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067254.html
> and is unrelated to Fortran.

Thanks for this.  The problem is with gfortran (gcc).  It is good to
know it is simply with gcc/gfortran and not a result of mixing libgcc
libraries.  The main point for users of math/R is that problems are only
triggered when it is built with gfortran and not with flang.  If we want
R to work as it should, we need flang, but if we have to switch all
Fortran ports to flang we will break (many) other ports.

> So I don't think any port actually needs flang right now and nothing would
> break if we added flang support using DEFAULT_VERSIONS.

Well, for some definition of need, math/R needs flang if you want to
download R packages without requiring user intervention.  There is
nothing inherent to flang that math/R requires.  It just needs a working
Fortran implementation.  Working for R means flang, working for other
ports means gfortran.

> You could then ask portmgr for an exp-run with the default set to
> flang to see where the problems are.  Point upstream flang developers
> and anyone else who wants to push flang to the error logs and
> prioritise fixing ports that cause the biggest fallout.  You'll get
> better results faster that way than when you expect individual port
> maintainers to experiment with flang or fix flang related issues.

I did this with a private poudriere run and there was a lot of breakage
with flang.  It was a few months ago though, so I will try again.  If a
high proportion break with flang, then I still feel it might be best (in
terms of breakage for users) to ease in with the current approach.  I
will report back soon(ish).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20171028/74bfa3cf/attachment.sig>