Further fix the case mentioned in rev. 1.302. The

intent was (and still is) that if a user has say
CPUTYPE=i686 set in /etc/make.conf, we don't print
the assignment type warning unless TARGET_CPUTYPE
is overridden.

Unfortunately, the implementation was buggy, and
only recent changes to bsd.cpu.mk that swapped
canonical and alias values of some CPU types made
the bug apparent.

Here's what happens here.

- CPUTYPE=i686 is set in /etc/make.conf,
- bsd.cpu.mk reset it to "pentiumpro",
- Makefile.inc1 compares this canonical value
  with the result of the following test,

make -f /dev/null CPUTYPE=pentiumpro -V CPUTYPE

and expects the result to be "pentiumpro" too,
but "i686" is returned, here's why.  We have two
CPUTYPE variables, global, set to "i686" in
/etc/make.conf, and command-line (of a higher
precedence), set to "pentiumpro".

The following part of bsd.cpu.mk,

.  elif ${CPUTYPE} == "i686"
CPUTYPE = pentiumpro

which is responsible for converting aliases to
canonical values, sees the value of the CPUTYPE
command-line variable first, "pentiumpro", and
no conversion is done -- the net effect is that
CPUTYPE global stays with its old value "i686",
and "make -V CPUTYPE" (which prints variables
in the global context) returns "i686".

The fix was to pass the CPUTYPE in the test above
as an environment variable instead of as a command
line variable, i.e.,

CPUTYPE=pentiumpro make -f /dev/null -V CPUTYPE

This time, CPUTYPE global is still set to "i686"
initially (by /etc/make.conf), and an envieronment
variable CPUTYPE (of a lower precedence) is set
to "pentiumpro".  The .elif sees it's set to
"i686" and resets it to "pentiumpro", and so
"make -V" returns "pentiumpro".

NB: these various types of make(1) variables can
be very painful, especially when combined with
"make -V".

0 files changed, 0 insertions, 0 deletions