Uses/compiler.mk does not trigger under RBPi

[José Pérez]

Hi Michelle,
this makes sense, there are two bugs.

1) there is a bug somewhere in Mk/* that pulls USES/compiler.mk in also 
when USES+=compiler is not specified, AND the processor is Intel/AMD (or 
at least not ARM)
2) the following ports Makefile are broken in the sense that they use 
COMPILER_TYPE but do not call for USES+=compiler properly
CANDIDATES=$(find /usr/ports -name Makefile -exec fgrep -l COMPILER_TYPE 
"{}" \;)

for c in ${CANDIDATES}; do
   [ -z "`awk '/USES/ && /compiler/' "${c}"`" ] && echo ${c}
done
/usr/ports/devel/arm-none-eabi-gcc/Makefile
/usr/ports/devel/gcc-arm-embedded/files/Makefile
/usr/ports/devel/powerpc64-xtoolchain-gcc/Makefile
/usr/ports/graphics/hugin/Makefile
/usr/ports/lang/gcc/Makefile
/usr/ports/lang/gcc5-devel/Makefile
/usr/ports/lang/gcc5/Makefile
/usr/ports/lang/gcc6-devel/Makefile

Do you agree?

Any ideas to help identify 1)? Thank you.

Regards,

---
José Pérez

El 2015-10-04 12:56, Michelle Sullivan escribió:
> Michelle Sullivan wrote:
>> José Pérez wrote:
>> 
>>> Hi Michelle,
>>> thank you for your suggestion. Is this another workaround?
>>> 
>> 
>> As far as I was aware if you need Uses/compiler.mk it should be
>> specified (there are params if a particular compiler/feature set is
>> required) with USES+=compiler
>> 
>> 
>>> I mean: many port Makefiles are affected, in the sense that when 
>>> built
>>> on Intel/AMD the ports just work because Uses/compiler.mk is sucked 
>>> in
>>> automatically, but it is not on ARM.
>>> 
>> 
>> But do they need Uses/compiler.mk ?  If so then it might be someone
>> screwed up, if they don't actually need it then that would be why it's
>> not specified.
>> 
>> 
>>> So, shall I report a bug on all the ports that use COMPILER_TYPE, or
>>> is there a way to have ARM trigger Uses/compiler.mk?
>>> 
>> 
>> If they use/require COMPILER_TYPE and don't specify USES+= compiler 
>> then
>> I would log a bug for each port and let the ports manager take care of
>> it as it's probably a change in default behavior that has caused the
>> mess... how many are we talking about?  10+, 100+, 1000+?
>> 
>> 
> 
> Another (additional) thought is that if amd64/i386 is automatically
> pulling in Uses/compiler.mk when it is not explicitly requested, one
> could consider that in itself a (the) bug.