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
Depends on:
Reported: 2015-10-04 22:39 UTC by pr
Modified: 2015-10-13 10:11 UTC (History)
3 users (show)

See Also:


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
        @${ECHO_CMD} ${LOCALBASE}
.include <bsd.port.mk>
me@raspberry-pi:~ % make

me@raspberry-pi:~ %

Note how in AMD64 it works:
me@amd64:~ % make
me@amd64:~ %

As a result some ports fail to build on platforms other than i386/amd64. In particular the following are affected:

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 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

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

  PR:		203540

Comment 2 Jan Beich freebsd_committer 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_FEATURES (underpopulated)
  COMPILER_VERSION (incompatible values)
Comment 3 Warner Losh freebsd_committer 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 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

  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

Comment 5 Warner Losh freebsd_committer 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 2015-10-13 10:11:21 UTC
Close: I believe the problem is fixed