Date: Sat, 28 Oct 2017 11:47:26 -0300 From: Joseph Mingrone <jrm@FreeBSD.org> To: Tijl Coosemans <tijl@FreeBSD.org> Cc: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, portmgr@FreeBSD.org Subject: Re: svn commit: r452962 - head/math/libRmath Message-ID: <86y3nvtjlt.fsf@phe.ftfl.ca> In-Reply-To: <20171028124843.56f8e8d3@kalimero.tijl.coosemans.org> (Tijl Coosemans's message of "Sat, 28 Oct 2017 12:48:51 %2B0200") References: <201710270052.v9R0qf7A058644@repo.freebsd.org> <20171027125130.39e98c9c@kalimero.tijl.coosemans.org> <86d158vcve.fsf@phe.ftfl.ca> <20171028124843.56f8e8d3@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tijl Coosemans <tijl@FreeBSD.org> writes: > On Fri, 27 Oct 2017 12:17:41 -0300 Joseph Mingrone <jrm@FreeBSD.org> wrot= e: >> Tijl Coosemans <tijl@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.=20=20 >>> USES arguments are the wrong mechanism for this in my opinion. >>> DEFAULT_VERSIONS seems much better to me. Users can then add >>> fortran=3Dgfortran or fortran=3Dflang 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=3Dfortran and no option= s. >>> 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.=20=20 >> 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=3D220359 >> [3] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221127 >> [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.ht= ml > https://lists.freebsd.org/pipermail/freebsd-current/2017-October/067254.h= tml > 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). --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEVbCTpybDiFVxIrrVNqQMg7DW754FAln0mH5fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUACgkQNqQMg7DW 756ygxAAlP1dpKmJQsaHdpyJe5PB5Y4GA2vpHUUp0ycu7wR6cTRPS/okwUf5tM/d ORlfdBaiT5rcon8Eqyuo1ejygJWE/m/UA/XLwlSKzQ9dT6AzbOXmPaaZu9uXQzr3 Q4uZXH+Tx8Gx5Q4imWiFyBa8UrXLEkgpX9V1nh9P1dwweZ1LOHp3YOnxrYQTld/d NSYPOWaNPhBgwGGNqqoCrrdBisEViSOI22iu0wTD5zbvHB8MYjreAZ12FG9lK38S RR0B1/SZX3PL44Mtm5feHK7TKEq17jKhH2t2oyYNWZgGE8nBhITPP9JPtQLCLA8A iK1x5N5MmtL3FSkeBk/YUwx0ogyLdttNOpEOnUUid3okopMDgbbOHFNTlTRnedce tM0t9LmnngDRwKMTm5Ni5kVazy25vTi1TtW8DEwWfMhEz2NIcTdFeJPUA4E+U/8t FYSVEC29HvkPbyhiKk8VfuhbX8wKyM4KLTk2EIMFaZCHQsSblOexGTqtaKxyJdX4 bORvyoSDvhk2R8wKVjXP0owoR0VN2XxnwakKrKCK3GGB0WMCLJXNYyuiHPpROKMg Gs60SDzvJuQH9uDK72kz7pHm/ICRU+83Ej71NebEs2GMV5u7MbTmzZajN3lhJfif 3IrvVNSd4euiiFhu4hxhW22jqFTEi3SeFXrDZAT121zVkEFXj60= =7Ny8 -----END PGP SIGNATURE----- --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86y3nvtjlt.fsf>