Date: Fri, 23 May 2014 08:37:26 -0600 From: Warner Losh <imp@bsdimp.com> To: Don Lewis <truckman@freebsd.org> Cc: ports@FreeBSD.org, current@FreeBSD.org Subject: Re: ports/INDEX building broken on 11.0-CURRENT Message-ID: <243F52EA-86E6-408C-8494-9955C26851FD@bsdimp.com> In-Reply-To: <201405132304.s4DN4UsH080601@gw.catspoiler.org> References: <201405132304.s4DN4UsH080601@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <truckman@freebsd.org> 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(__<bsd.compiler.mk>__) > __<bsd.compiler.mk>__: >=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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?243F52EA-86E6-408C-8494-9955C26851FD>