Date: Fri, 27 Oct 2017 12:17:41 -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: <86d158vcve.fsf@phe.ftfl.ca> References: <201710270052.v9R0qf7A058644@repo.freebsd.org> <20171027125130.39e98c9c@kalimero.tijl.coosemans.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--=-=-= Content-Type: text/plain Tijl Coosemans <tijl@FreeBSD.org> writes: > On Fri, 27 Oct 2017 00:52:41 +0000 (UTC) Joseph Mingrone <jrm@FreeBSD.org> wrote: >> Author: jrm >> Date: Fri Oct 27 00:52:41 2017 >> New Revision: 452962 >> URL: https://svnweb.freebsd.org/changeset/ports/452962 >> Log: >> math/libRmath: Update to version 3.4.2 and add an option on amd64 to choose >> the fortran compiler. >> Modified: >> head/math/libRmath/Makefile >> head/math/libRmath/distinfo >> Modified: head/math/libRmath/Makefile >> ============================================================================== >> --- head/math/libRmath/Makefile Thu Oct 26 22:56:58 2017 (r452961) >> +++ head/math/libRmath/Makefile Fri Oct 27 00:52:41 2017 (r452962) >> @@ -2,8 +2,7 @@ >> # $FreeBSD$ >> PORTNAME= libRmath >> -PORTVERSION= 3.4.1 >> -PORTREVISION= 1 >> +PORTVERSION= 3.4.2 >> CATEGORIES= math lang >> MASTER_SITES= CRAN/src/base/R-${PORTVERSION:C|\..*||} >> DISTNAME= R-${DISTVERSIONPREFIX}${DISTVERSION}${DISTVERSIONSUFFIX} >> @@ -13,6 +12,8 @@ COMMENT= Standalone math library from R >> LICENSE= GPLv2 >> +ONLY_FOR_ARCHS= aarch64 amd64 i386 >> + >> LIB_DEPENDS= libcurl.so:ftp/curl \ >> libpcre.so:devel/pcre >> @@ -23,11 +24,28 @@ CONFIGURE_ARGS= --disable-nls --with-ICU=no --with-cai >> --without-libintl-prefix >> CONFIGURE_ENV+= ac_cv_header_iconv_h=no >> GNU_CONFIGURE= yes >> -RMATH_SOVERSION=3 >> -USES= fortran localbase >> +RMATH_SOVERSION=${PORTVERSION:R} >> +USES= localbase >> USE_LDCONFIG= yes >> PLIST_SUB= RMATH_SOVERSION="${RMATH_SOVERSION}" >> + >> +OPTIONS_SINGLE= FORTRAN >> +OPTIONS_SINGLE_FORTRAN= ${OPTIONS_SINGLE_FORTRAN_${MACHINE_ARCH}} >> +OPTIONS_SINGLE_FORTRAN_amd64= GFORTRAN FLANG >> +OPTIONS_DEFAULT_amd64= FLANG >> + >> +FLANG_DESC= Build Fortran source with flang >> +GFORTRAN_DESC= Build Fortran source with gfortran >> + >> +GFORTRAN_USES= fortran:gcc >> +FLANG_USES= fortran:flang >> + >> +.include <bsd.port.options.mk> >> + >> +.if ${ARCH} != amd64 >> +USES+= fortran:gcc >> +.endif > 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEEVbCTpybDiFVxIrrVNqQMg7DW754FAlnzThVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDU1 QjA5M0E3MjZDMzg4NTU3MTIyQkFENTM2QTQwQzgzQjBENkVGOUUACgkQNqQMg7DW 757jGQ/8Dcvkey6bqDXovr0Qs4+Ag3J22NJMPDg6bd5ta6EihNXg7q2G3Vj7SHnB h4+fvTcVFIjOgksQ2Sq/KmKuB/k4Zu7chr/1L5tFRHunm5qftVjss/oASBqtunT4 ymiKapMAeyvE1uWvX5ObJKaD7cp/H+4BiBoArbZ8/K3zQbH/Aa1n07ycXp3AT1MO 9uR8Oq0fNiHRtteqBjZvFPmIzRKISaCgEccm5adoiI52myqINh1Xms0UAuqnQqfq PNkOkH49KxTXvSqimC6mdc12vJwXpr1UewVsX+TvKeF0Ht15aP6FXvGrLChRb+jo s1XyMO8an4fLpQXQMcjJ4gp7dxlGB3ClfCCD6rbKZSB3imOHMvuizmuWlLYsrvcW z4Tqkhvkl/buU/7OOO/WynO3MA+li4TQoWz1Xg+ybhrFmKOvGZuj5XvL4E/6i1QQ LBAl3zfRyalKvyNeSg5mKDOlGS6OPyasMQea/Fgh27VscKUjo1vjXMHvNE6+vBpM 6W9OCbPGMesna+F91KP50srWygb6FcGTbLJG8XxFP67PtQHN4LC1w9NrwhfPcyVZ 35vFiap3sWN0fGTQ/kCfo1h/2BsNz0zFutZTYOjaM2YS0pxG/LExJt7A0gzv4d1E RPFf+bsftZAJhrD5kwhx+MCFlpeLjEeDXcZofWk9YZ9zW180KxY= =BIlR -----END PGP SIGNATURE----- --=-=-=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86d158vcve.fsf>