From owner-svn-ports-all@FreeBSD.ORG Thu Feb 27 13:57:51 2014 Return-Path: Delivered-To: svn-ports-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 94731781; Thu, 27 Feb 2014 13:57:51 +0000 (UTC) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 904701B38; Thu, 27 Feb 2014 13:57:50 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoGAPpCD1NR8Zjl/2dsb2JhbABagwY7wWKBGhd0giUBAQQBOhwjBQsLFAQJJQ8qHgaIBAwBCMpVF41zEQEdMweENwSYN4EzkHiDLjuBNQ Received: from 229.152-241-81.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([81.241.152.229]) by relay.skynet.be with ESMTP; 27 Feb 2014 14:56:40 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.8/8.14.8) with ESMTP id s1RDuchU002778; Thu, 27 Feb 2014 14:56:39 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Thu, 27 Feb 2014 14:56:38 +0100 From: Tijl Coosemans To: Gerald Pfeifer Subject: Re: svn commit: r336343 - in head: . Mk/Uses Message-ID: <20140227145638.4d6d9307@kalimero.tijl.coosemans.org> In-Reply-To: References: <201312131322.rBDDMWZC038800@svn.freebsd.org> <20131217215533.3c0d9fcb@kalimero.tijl.coosemans.org> <20131217210048.GM99753@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: svn-ports-head@freebsd.org, Baptiste Daroussin , svn-ports-all@freebsd.org, ports-committers@freebsd.org X-BeenThere: svn-ports-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the ports tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 13:57:51 -0000 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.