On May 13, 2014, at 5:04 PM, Don Lewis <truck...@freebsd.org> wrote:
> On 13 May, To: po...@freebsd.org wrote: >> Please excuse the crosspost. I'm not sure if this is a ports problem or >> a CURRENT problem. >> >> 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/*. >> >> # 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. >> ===> devel/ccons failed >> *** [describe.devel] Error code 1 >> >> make[2]: stopped in /usr/ports >> 1 error >> >> make[2]: stopped in /usr/ports >> >> ******************************************************************** >> 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 po...@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). >> >> Note: the latest pre-generated version of INDEX may be fetched >> automatically with "make fetchindex". >> ******************************************************************** >> >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/ports >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports >> >> >> If I go to the offending port: >> >> # 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. >> >> >> I don't have any problems building the INDEX file on 9.3-PRERELEASE >> r265940. > > 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’d 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. > > 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’t 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: > > .if ${COMPILER_TYPE} == gcc && ${COMPILER_VERSION} < 46 > USE_GCC= yes > .endif > > 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’t fit quite right…. > Index: share/mk/bsd.compiler.mk > =================================================================== > --- 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>__: > > -_v!= ${CC} --version > .if !defined(COMPILER_TYPE) > -. if ${CC:T:Mgcc*} > +. if ${CC:T:M*gcc*} > COMPILER_TYPE:= gcc > -. elif ${CC:T:Mclang} > +. elif ${CC:T:Mclang*} > COMPILER_TYPE:= clang > -. elif ${_v:Mgcc} > +. else > +_v!= ${CC} --version > +. if ${_v:Mgcc} > COMPILER_TYPE:= gcc > -. elif ${_v:M\(GCC\)} > +. elif ${_v:M\(GCC\)} > COMPILER_TYPE:= gcc > -. elif ${_v:Mclang} > +. elif ${_v:Mclang} > COMPILER_TYPE:= 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!= ${CC} --version || echo 'unknown' > +. endif > COMPILER_VERSION!=echo ${_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’t be set now almost all the time. This will break some use cases that we’d hope to gain by doing this in the first place. It looks like it doesn’t matter so much to the INDEX generation. I just committed a simpler fix that doesn’t break the other things. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
