Bug 203540 - Mk/Uses/compiler.mk gets called automatically only on some platforms and not on others
Summary: Mk/Uses/compiler.mk gets called automatically only on some platforms and not ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: arm Any
: --- Affects Many People
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-10-04 22:39 UTC by pr
Modified: 2015-10-13 10:11 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pr 2015-10-04 22:39:02 UTC
Mk/Uses/compiler.mk is triggered automatically on some platforms, I can test i386 and amd64 and not on other, I can test arm6.

me@raspberry-pi:~ % cat Makefile
all:
        @${ECHO_CMD} ${LOCALBASE}
        @${ECHO_CMD} ${COMPILER_TYPE}
.include <bsd.port.mk>
me@raspberry-pi:~ % make
/usr/local

me@raspberry-pi:~ %

Note how in AMD64 it works:
me@amd64:~ % make
/usr/local
clang
me@amd64:~ %

As a result some ports fail to build on platforms other than i386/amd64. In particular the following are affected:
devel/arm-none-eabi-gcc
devel/powerpc64-xtoolchain-gcc
graphics/hugin
lang/gcc
lang/gcc5-devel
lang/gcc5
lang/gcc6-devel

This is because their Makefiles relay on COMPILER_TYPE (defined by Mk/Uses/compiler.mk) but they don't explicitly ask for
USES+= compiler
Comment 1 commit-hook freebsd_committer freebsd_triage 2015-10-05 17:00:16 UTC
A commit references this bug:

Author: antoine
Date: Mon Oct  5 16:59:52 UTC 2015
New revision: 398656
URL: https://svnweb.freebsd.org/changeset/ports/398656

Log:
  Add missing USES=compiler, needed for ${COMPILER_TYPE} checks

  PR:		203540

Changes:
  head/lang/gcc/Makefile
  head/lang/gcc5/Makefile
  head/lang/gcc5-devel/Makefile
  head/lang/gcc6-devel/Makefile
Comment 2 Jan Beich freebsd_committer freebsd_triage 2015-10-06 00:29:17 UTC
The submitter didn't mention FreeBSD version but the issue likely comes from namespace pollution caused by bsd.compiler.mk implicitly included by bsd.own.mk via bsd.port.mk. It appears to be a regression from base r264661 and base r265420 (both only in /head) which moved bsd.compiler.mk outside of _WITHOUT_SRCCONF conditional defined in bsd.port.mk.

Both /usr/share/mk/bsd.compiler.mk and /usr/ports/Mk/Uses/compiler.mk define the following variables:

  COMPILER_TYPE
  COMPILER_FEATURES (underpopulated)
  COMPILER_VERSION (incompatible values)
Comment 3 Warner Losh freebsd_committer freebsd_triage 2015-10-06 03:14:13 UTC
We now use COMPILER_TYPE extensively in the build and in the other bsd.*.mk files,
so it was moved out from under the _WITHOUT_SRCCONF define. In 10.x, we mostly just used it to determine what to build. In current (and some MFC'd stuff) we use it to add compiler flags and do conditional things based on what compiler we're using. It is not a regression, but a new feature.

ports could adjust by undefining things after including bsd.own.mk. It's kinda half using bsd.*.mk files and half not.

src could cope by renaming things. While this was in a release, it wasn't documented in 10.x as a thing that could be used. Chances are good it's leaked into downstream builds though.

It might also be possible to move where we include it, but then COMPILER_FEATURES wouldn't be defined in bsd.srcopt.mk. This might actually be the least intrusive way to fix it if I can get the depends right.
Comment 4 commit-hook freebsd_committer freebsd_triage 2015-10-06 04:19:09 UTC
A commit references this bug:

Author: imp
Date: Tue Oct  6 04:18:49 UTC 2015
New revision: 288911
URL: https://svnweb.freebsd.org/changeset/base/288911

Log:
  Previous versions of bsd.own.mk included bsd.compiler.mk
  only when _WITHOUT_SRCCONF wasn't defined. Restore this
  behavior because bsd.ports.mk depends on this in subtle
  ways. The compat include of bsd.compiler.mk should
  be removed in 12 anyway.

  PR:	203540

Changes:
  head/share/mk/bsd.own.mk
Comment 5 Warner Losh freebsd_committer freebsd_triage 2015-10-06 13:13:26 UTC
Turns out that we already included bsd.compiler.mk all the places we need it and only included it in bsd.own.mk for compat. So it was easy to make things a little more compat.
Comment 6 Antoine Brodin freebsd_committer freebsd_triage 2015-10-13 10:11:21 UTC
Close: I believe the problem is fixed