From owner-freebsd-ports@FreeBSD.ORG Fri May 23 14:37:23 2014 Return-Path: Delivered-To: ports@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 9AC6769C for ; Fri, 23 May 2014 14:37:23 +0000 (UTC) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 611622391 for ; Fri, 23 May 2014 14:37:23 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id rl12so4949559iec.23 for ; Fri, 23 May 2014 07:37:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=bw2p31xn7TLj5L1XnFU15EnPwuvIXVg6CkDY/j7tIxw=; b=fXwLle0S5WD/vWW2R7xKHsa7ccsv0ImV2K/vXfl4EDhGrib2ZDva8e+R0kOTTgxVt/ J1z9NxIBkLfGgrGns4imSiqFIPAnb6FejX1nub/nM74IxDon/e+xZeGjfBOKKFxqEUP8 57wTlVFBqGVFQCj3SIk1y0bu142ktMmAQiOqEGv5mRdsm1VuWyuopPV5lTofKX3kA8wS Hg9Rrk655WFxuSkcU4Qbnw3+McnW9p7lG/UQtA+xJgg1AYDCunS05Y5MJFLo3v0/lC84 nHeEnoLyiMtg09zNoPAox6qrE/i8k5N+pJbRQK0Gp6zOXcRpwIdsVMkfdjr7PGVGd88s favw== X-Gm-Message-State: ALoCoQngEEAW0GjlmbPqN3eOVZBgDBRs2qI/X4DeE+JN29GVJ/cnWdr0cl/owNAuCMnydl5E+YlG X-Received: by 10.43.74.198 with SMTP id yx6mr5157074icb.40.1400855841822; Fri, 23 May 2014 07:37:21 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id s1sm4514802igr.14.2014.05.23.07.37.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 23 May 2014 07:37:21 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_4E1AF209-3B96-4181-9888-A72509512A93"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) Subject: Re: ports/INDEX building broken on 11.0-CURRENT From: Warner Losh In-Reply-To: <201405132304.s4DN4UsH080601@gw.catspoiler.org> Date: Fri, 23 May 2014 08:37:26 -0600 Message-Id: <243F52EA-86E6-408C-8494-9955C26851FD@bsdimp.com> References: <201405132304.s4DN4UsH080601@gw.catspoiler.org> To: Don Lewis X-Mailer: Apple Mail (2.1878.2) Cc: ports@FreeBSD.org, current@FreeBSD.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 14:37:23 -0000 --Apple-Mail=_4E1AF209-3B96-4181-9888-A72509512A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 13, 2014, at 5:04 PM, Don Lewis wrote: > On 13 May, To: ports@freebsd.org wrote: >> Please excuse the crosspost. I'm not sure if this is a ports problem = or >> a CURRENT problem. >>=20 >> I just updated my 11.0-CURRENT machine to r265940 and can no longer >> build ports/INDEX-11. My ports tree is r353903. I think this = problem >> is being caused by the recent changes to /usr/share/mk/*. >>=20 >> # make index >> Generating INDEX-11 - please wait..--- describe.accessibility --- >> --- describe.arabic --- >> --- describe.archivers --- >> --- describe.astro --- >> --- describe.audio --- >> --- describe.benchmarks --- >> --- describe.biology --- >> --- describe.cad --- >> --- describe.chinese --- >> --- describe.comms --- >> --- describe.converters --- >> --- describe.databases --- >> --- describe.deskutils --- >> --- describe.devel --- >> clang33: not found >> make[5]: "/usr/share/mk/bsd.compiler.mk" line 24: warning: "clang33 = --version" returned non-zero status >> make[5]: "/usr/share/mk/bsd.compiler.mk" line 37: Unable to determine = compiler type for clang33. Consider setting COMPILER_TYPE. >> =3D=3D=3D> devel/ccons failed >> *** [describe.devel] Error code 1 >>=20 >> make[2]: stopped in /usr/ports >> 1 error >>=20 >> make[2]: stopped in /usr/ports >>=20 >> ******************************************************************** >> Before reporting this error, verify that you are running a supported >> version of FreeBSD (see http://www.FreeBSD.org/ports/) and that you >> have a complete and up-to-date ports collection. (INDEX builds are >> not supported with partial or out-of-date ports collections. >> If that is the case, then >> report the failure to ports@FreeBSD.org together with relevant >> details of your ports configuration (including FreeBSD version, >> your architecture, your environment, and your /etc/make.conf >> settings, especially compiler flags and OPTIONS_SET/UNSET settings). >>=20 >> Note: the latest pre-generated version of INDEX may be fetched >> automatically with "make fetchindex". >> ******************************************************************** >>=20 >> *** Error code 1 >>=20 >> Stop. >> make[1]: stopped in /usr/ports >> *** Error code 1 >>=20 >> Stop. >> make: stopped in /usr/ports >>=20 >>=20 >> If I go to the offending port: >>=20 >> # cd /usr/ports/devel/ccons/ >> # make describe >> clang33: not found >> make: "/usr/share/mk/bsd.compiler.mk" line 24: warning: "clang33 = --version" returned non-zero status >> make: "/usr/share/mk/bsd.compiler.mk" line 37: Unable to determine = compiler type for clang33. Consider setting COMPILER_TYPE. >>=20 >>=20 >> I don't have any problems building the INDEX file on 9.3-PRERELEASE >> r265940. >=20 > Various ports were setting CC to the following, which was causing the > bsd.compiler.mk to barf: > clang32 > clang33 > /usr/bin/gcc > mingw32-gcc > gcc Yea, the actual problem is that it assumed that the CC you=92d set = actually existed on the system. Not unreasonable in the building = /usr/src context, but less reasonable in this context... > The patch below allowed me to successfully run "make index" and = reduced > the error spewage. It also greatly reduces the need to run > ${CC} --version > in order to set COMPILER_TYPE. >=20 > It still seems like a great waste to run > ${CC} --version > for each port to set COMPILER_VERSION since only a handful of ports = need > this information. Unfortunately, you can=92t do that. You must know the version of the = compiler in the bsd.*.mk system now. It is unfortunate that ports system users = this aspect of tree, or at least that it slows things down a bit. > Then there is this sort of circular dependency in some ports, like = this > one in textproc/ibus/Makefile: >=20 > .if ${COMPILER_TYPE} =3D=3D gcc && ${COMPILER_VERSION} < 46 > USE_GCC=3D yes > .endif >=20 > This will cause CC to be redefined, but COMPILER_TYPE and > COMPILER_VERSION will still retain their old values. This suggests that ports might be better served by another mechanism, = since this one doesn=92t fit quite right=85. > Index: share/mk/bsd.compiler.mk > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/mk/bsd.compiler.mk (revision 265940) > +++ share/mk/bsd.compiler.mk (working copy) > @@ -21,23 +21,28 @@ > .if !target(____) > ____: >=20 > -_v!=3D ${CC} --version > .if !defined(COMPILER_TYPE) > -. if ${CC:T:Mgcc*} > +. if ${CC:T:M*gcc*} > COMPILER_TYPE:=3D gcc =20 > -. elif ${CC:T:Mclang} > +. elif ${CC:T:Mclang*} > COMPILER_TYPE:=3D clang > -. elif ${_v:Mgcc} > +. else > +_v!=3D ${CC} --version > +. if ${_v:Mgcc} > COMPILER_TYPE:=3D gcc > -. elif ${_v:M\(GCC\)} > +. elif ${_v:M\(GCC\)} > COMPILER_TYPE:=3D gcc > -. elif ${_v:Mclang} > +. elif ${_v:Mclang} > COMPILER_TYPE:=3D clang > -. else > +. else > .error Unable to determine compiler type for ${CC}. Consider setting = COMPILER_TYPE. > +. endif > . endif > .endif > .if !defined(COMPILER_VERSION) > +. if !defined(_v) > +_v!=3D ${CC} --version || echo 'unknown' > +. endif > COMPILER_VERSION!=3Decho ${_v:M[1-9].[0-9]*} | awk -F. '{print $$1 * = 10000 + $$2 * 100 + $$3;}' > .endif > .undef _v I think this will mean that COMPILER_VERSION won=92t be set now almost = all the time. This will break some use cases that we=92d hope to gain by = doing this in the first place. It looks like it doesn=92t matter so much = to the INDEX generation. I just committed a simpler fix that doesn=92t break the other things. Warner --Apple-Mail=_4E1AF209-3B96-4181-9888-A72509512A93 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTf10mAAoJEGwc0Sh9sBEA7WwP/imWJmjOvUcQWurJYsVt7RlR 6ZrvSFNmyA5Yn0I4XxVfzPHknOGtN0eSWVyEyt1eRRFmeRyVAkfpyQTA++e9FDf5 wt3CjklpoZEUYN5HEScWUxjxOI9RXUdkPVE1CI7k0hurNyr8rxhLclIVMZ0kz/8G DKNPI8xrXljMr2erQBEwjgAKgo00BEx9uOOIf91e+2w9EYjM7kaNbJmAm4D2y9HS kF0ZCBptyASW1d+PXs+M6sssl4VSPUGMwDHhT3ujVUdyhPl9jcH4jagYSDBN4ToZ +GRYUKvrt+FkgAEmLlTQi2VIbOu7790jKzCE//OhFcp/87Z0E3cNAzjIvI08FKHI Xu8jnYowkQDR/aKj91sTJQ+vz+qZpBvsedOnOXRVBdStQy9eSuXrI8xeiFPV6+kw nUwfBKcOSoOG74JIOwt1a+wwUYqnhnES3NNN8hFMA5rW7AIpyw0rephqoAvRSQw9 EVjGGDt4i7XXcl9kVyAFwF4XpT8q7aJYYFXRpEtPlDKSaD+MKgPSNti2N4QW1l6r tFn3ReyanJMLZQGxvahi4mOY9j+cE2H/PuTpN3HIE1ArpJyuFyep7FM875ldhAiS eZG47AntIOBIhmGQxdUpckdLHyyKmJjSVMgvyV9CUHLyb2LdP6r1uhpT5jajsJ2d PJABStdv3KzsO6Ao+S2B =lfWv -----END PGP SIGNATURE----- --Apple-Mail=_4E1AF209-3B96-4181-9888-A72509512A93--