Date: Sun, 04 Oct 2015 19:56:01 +0200 From: Michelle Sullivan <michelle@sorbs.net> To: =?UTF-8?B?Sm9zw6kgUMOpcmV6?= <fbl@aoek.com> Cc: freebsd-arm@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Uses/compiler.mk does not trigger under RBPi Message-ID: <56116831.1050504@sorbs.net> In-Reply-To: <a67b09419a2ec9e1cad68bc631ea31df@mail.yourbox.net> References: <bfe1c24f878ca90245680b2cfae1f6d2@mail.yourbox.net> <560DCFD7.30509@sorbs.net> <c5f4ab0adc751410b8205e6f3aedda57@mail.yourbox.net> <560FAAA4.6080800@sorbs.net> <561105DD.1030903@sorbs.net> <a67b09419a2ec9e1cad68bc631ea31df@mail.yourbox.net>
next in thread | previous in thread | raw e-mail | index | archive | help
José Pérez wrote:
> 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)
I would agree this is probably one or two bugs in itself. One would say
it should not automatically pull in Uses/compiler.mk under any
circumstances without USES+=compiler being specified in the port
Makefile otherwise what's the point of the 'option'...
> 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
>
Have not looked into the list, will take your word for it. However I
would also say this is not 'lots', but it is something that portmgr
should probably have taken care of because this stinks of patching the
build system without proper testing. (ie rudimentary testing on amd64,
it works, ship it...!) Of course I'm only a user not a comitter and a
frequent complainer about people breaking s**t by just changing stuff
without any sort of proper change control other than, we need it, it
works on my system so lets ship it...
> Do you agree?
>
> Any ideas to help identify 1)? Thank you.
I could, but not right now, and to be perfectly honest - it's something
that probably lies with portmgr@ .. you should log bugs for this, I
would suggest in the initial instance just the one with a list of ports
that should be updated along with it, and mark it 'affects many'...
hopefully someone will take the time to pick it up and fix it.
Regards,
Michelle
>
> 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.
> _______________________________________________
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org"
--
Michelle Sullivan
http://www.mhix.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56116831.1050504>