Re: ports/INDEX building broken on 11.0-CURRENT
--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--
討論串 (同標題文章)
完整討論串 (本文為第 3 之 3 篇)：