From owner-svn-ports-head@freebsd.org Sat Oct 28 15:14:47 2017 Return-Path: Delivered-To: svn-ports-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40B67E45B10 for ; Sat, 28 Oct 2017 15:14:47 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 030DA72029 for ; Sat, 28 Oct 2017 15:14:46 +0000 (UTC) (envelope-from jrm@ftfl.ca) Received: by mail-qk0-f176.google.com with SMTP id q83so11560895qke.6 for ; Sat, 28 Oct 2017 08:14:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Wx2BDE+6pqDn2503up0TpyW0rNpxAOqDzdrY4SZz0ro=; b=T2wbEkwkXnHxHfFHoFpq0VeowT8K6G5j80qgu22Et+0DQPM7+uPhwgcGNXgt/sYMT0 ZhGq1ru0zy/W4Q7UV/VTY02djS2tF8OOtE1zR2BHyWiwQUXELcBhbxiBMDL6X+y2ZoaA eHAwvnJDY1TGSUVLnuxQwba+YfxY9zADVbWSduX9untDRfv0fVR6+qy7Rr9Gvj7zVvSi 0RFDPfy2FPxuh6UUSWDJeYXEnSZYfgxXNxsd7WIxwf3L6lmCDzzoZ/yXXfpwRm6mzi2C /xsNZUhscXxuyHfMSXzaShVCxbTWWYrP0la5WzJluc13Dl3ZV1CHXUZIP9YXMAYl6GNK ulvw== X-Gm-Message-State: AMCzsaV5lOybNdPKrkWPR56kY2gbC9dNtpc4ep11tUkZPJ9+ToPqOykd 8SY2QMvnNlPUI64NePTw/1jNHQ== X-Google-Smtp-Source: ABhQp+TvjxlD4zYw2w3udzoxzulAgY/61nS1q29n8Mm7XJjPnn3AkNsccnL8KMlw4jBVoFF16Sh8RQ== X-Received: by 10.55.33.150 with SMTP id f22mr5345322qki.207.1509202049381; Sat, 28 Oct 2017 07:47:29 -0700 (PDT) Received: from phe.ftfl.ca.ftfl.ca (hlfxns017vw-142-68-134-140.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.68.134.140]) by smtp.gmail.com with ESMTPSA id u48sm6881991qtk.77.2017.10.28.07.47.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 28 Oct 2017 07:47:27 -0700 (PDT) From: Joseph Mingrone To: Tijl Coosemans 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 References: <201710270052.v9R0qf7A058644@repo.freebsd.org> <20171027125130.39e98c9c@kalimero.tijl.coosemans.org> <86d158vcve.fsf@phe.ftfl.ca> <20171028124843.56f8e8d3@kalimero.tijl.coosemans.org> Date: Sat, 28 Oct 2017 11:47:26 -0300 In-Reply-To: <20171028124843.56f8e8d3@kalimero.tijl.coosemans.org> (Tijl Coosemans's message of "Sat, 28 Oct 2017 12:48:51 +0200") Message-ID: <86y3nvtjlt.fsf@phe.ftfl.ca> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: svn-ports-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the ports tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2017 15:14:47 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tijl Coosemans writes: > On Fri, 27 Oct 2017 12:17:41 -0300 Joseph Mingrone wrot= e: >> Tijl Coosemans 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----- --=-=-=--