Date: Thu, 27 Feb 2014 14:56:38 +0100 From: Tijl Coosemans <tijl@FreeBSD.org> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: svn-ports-head@freebsd.org, Baptiste Daroussin <bapt@FreeBSD.org>, svn-ports-all@freebsd.org, ports-committers@freebsd.org Subject: Re: svn commit: r336343 - in head: . Mk/Uses Message-ID: <20140227145638.4d6d9307@kalimero.tijl.coosemans.org> In-Reply-To: <alpine.LSU.2.11.1402242318220.2233@tuna.site> References: <201312131322.rBDDMWZC038800@svn.freebsd.org> <alpine.LSU.2.11.1312160847420.2366@tuna.site> <20131217215533.3c0d9fcb@kalimero.tijl.coosemans.org> <20131217210048.GM99753@ithaqua.etoilebsd.net> <alpine.LSU.2.11.1402242318220.2233@tuna.site>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 26 Feb 2014 23:03:08 +0100 (CET) Gerald Pfeifer wrote: > On Tue, 17 Dec 2013, Baptiste Daroussin wrote: >>> To address the redundancy I think there are a number of things we >>> can do: >>> - I expect converting Fortran ports will be relatively straightforward >>> so the Fortran bits in bsd.gcc.mk can eventually be removed. > > This created more redundancy (and there will be more necessary > unless the technical approach is revised to include the GCC > handling code from Uses/fortran.mk if this is possible). > > And it makes USES=fortran picking up the compiler specified with > USE_GCC=X.Y, as a number of committers/users have asked the last > months, harder. I had an idea how to handle this. Not so any more. > > And it lost the documentation describing the knob a bit, such as > the version of GCC being pulled in. > > > It really would have been nice, not to say appropriate, to at least > share the patch that moved some chunks from a file maintained by me > for years (and carrying my name as maintainer) with me up front. > > This is the second time, though with a different portmgr approving > this one, within two months. Not a happy experience on my side. :-( > > (Rene, on the other hand, suggested two patches in the same time > frame and I managed to review and approve even while my notebook > was broken. That is how I'd like to see FreeBSD work.) I'm sorry you feel this way, but this is not how I experienced this. I initially intended for ports to be converted one by one to USES=fortran. Your original email in this thread about the redundancy and complexity of having two Fortran mechanisms made me think it would be better to speed up that process, so I sent the message you quoted above. Baptiste gave his approval to that approach and because you didn't voice any concerns or objections I assumed I had the green light. First, all unmaintained ports were converted and two weeks later I submitted a patch to convert the rest. That patch was only committed recently because it took that long to get an exp-run. It finally fixed several more ports that combine C++ and Fortran code. These ports need to have that C++ code compiled with Clang/libc++ and that is why the selection of the Fortran compiler has been separated completely from the selection of the C/C++ compiler. Fixing these ports was more important to me than some redundancy under Mk/, but with that done now, yes, let's see if we can improve Mk (although I'm kind of busy right now dealing with libtool and iconv issues). > And it makes USES=fortran picking up the compiler specified with > USE_GCC=X.Y, as a number of committers/users have asked the last > months, harder. There are no ports with that combination at the moment, but I'm also not sure it would be a good thing to let the choice of Fortran compiler depend on USE_GCC=x.y. It's much safer to have all Fortran code on a system compiled with one compiler. >>> - Use the bsd.default-versions.mk framework to set GCC_DEFAULT. This >>> allows users to set their preferred version of GCC in make.conf and >>> provides a central place where both fortran.mk and compiler.mk can >>> pick up the default GCC version instead of each having it hardcoded. >> I would love to see all of the above happening > > Done per the patch below. > > IMHO that should have been patch #1, to introduce that central knob. > > Gerald > > ======== snip ======== > Author: gerald > Date: Mon Feb 24 22:15:32 2014 > New Revision: 345903 > URL: http://svnweb.freebsd.org/changeset/ports/345903 > QAT: https://qat.redports.org/buildarchive/r345903/ > > Log: > Replace all uses of GCC_DEFAULT_VERSION by GCC_DEFAULT, remove the > definition of the former from Mk/bsd.gcc.mk and add the latter -- > still set to 4.6 -- to Mk/bsd.default-versions.mk. > > Include Mk/bsd.default-versions.mk from Mk/bsd.gcc.mk to tie the > two together. > > Modified: > head/Mk/bsd.default-versions.mk > head/Mk/bsd.gcc.mk > > Modified: head/Mk/bsd.default-versions.mk > ============================================================================== > --- head/Mk/bsd.default-versions.mk Mon Feb 24 22:15:01 2014 (r345902) > +++ head/Mk/bsd.default-versions.mk Mon Feb 24 22:15:32 2014 (r345903) > @@ -18,6 +18,7 @@ ${_l:U}_DEFAULT= ${lang:C/.*=//g} > .endfor > > APACHE_DEFAULT?= 2.2 > +GCC_DEFAULT?= 4.6 I need to think about this some more, but what I'd like to see in fortran.mk is this change (in pseudo-diff): .include "${PORTSDIR}/Mk/bsd.default-versions.mk" _GCC_VER= ${GCC_DEFAULT:S/.//} -BUILD_DEPENDS+=gfortran${_GCC_VER}:${PORTSDIR}/lang/gcc -RUN_DEPENDS+= gfortran${_GCC_VER}:${PORTSDIR}/lang/gcc +BUILD_DEPENDS+=gfortran${_GCC_VER}:${PORTSDIR}/lang/gcc${_GCC_VER} +RUN_DEPENDS+= gfortran${_GCC_VER}:${PORTSDIR}/lang/gcc${_GCC_VER} When a user adds something like "DEFAULT_VERSIONS= gcc=4.8 ruby=2.0 ..." to /etc/make.conf this would make USES=fortran depend on lang/gcc48. But this requires the following change in bsd.default-version.mk to work correctly with lang/gcc (without version suffix): -GCC_DEFAULT?= 4.6 +GCC_DEFAULT?= # empty And also, lang/gcc would have to install "gfortran" as a symlink maybe to gfortran46. I don't really like this bit, so maybe fortran.mk should simply be taught that gfortran${_GCC_VER} with empty ${_GCC_VER} means gfortran46. Or maybe lang/gcc46 should be removed and lang/gcc renamed lang/gcc46. Then there would only be lang/gccXY ports similar to Perl, PHP, Ruby,... ports. The older gccXY versions would only get release updates and the newer gccXY would still get the snapshot updates.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140227145638.4d6d9307>