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".
building the kerberos5 includes. This is not the same patch that
Bjoern A. Zeeb came up with, but the credit still goes to him for finding
the problem. Thanks!
If turned on no NIS support and related programs will be built.
Lost parts rediscovered by: Danny Braniss <danny at cs.huji.ac.il>
PR: bin/68303
No objections: des, gshapiro, nectar
Reviewed by: ru
Approved by: rwatson (mentor)
MFC after: 2 weeks
It was pointed out to me that the convention we have is to use WITH_
elsewhere in the system, eg: ports etc. This is all temporary anyway
and presumably will be inverted to a NO_LIB32 or something like it in
the future.
rates pretty high on the "hack!" scale, but it works for me. Adding
-DWANT_LIB32 to the world build command line, or 'WANT_LIB32=yes' to
/etc/make.conf will include the 32 bit libraries with the build.
I have not made this default behavior. Cross compiling this stuff is an
adventure I have not investigated.
This is still a WIP. We needed this at work so that we could install from
a readonly obj tree - lib32/build.sh wasn't up to that.
NO_BIND_DNSSEC, NO_BIND_ETC, NO_BIND_NAMED, and NO_BIND_UTILS.
2. Make creation of directories in /usr/include that are only needed
in the WITH_BIND_LIBS case conditional.
Reviewed by: ru, des
libpthread is provided by src/lib/libc_r.
Also, removed lib/bind from _generic_libs, "lib" will suffice.
Also, removed redundant lib/bind dependency on lib/libpthread
(as lib/bind is not in the _prebuild_libs, it's not needed).
Prodded by: trhodes@ reporting that des@ is on the flight
the US Senate, Canadian Parliament and Australian Senate, it was
causing some confusion. After some consultation with Mark Murray,
change this to 'without objection' since often times a plain-speaking
term is preferable to a regionally used term.
Also, clarify that this procedure is to be used when for more mundane
matters that need a sanity check, but don't need the whole, ponderous
voting proceedure that more difficult issues require. Core members
that read email in any given 48 hour period are trusted enough to know
the difference and to provide the sanity check as necessary.
Reviewed by: markm
to make(1) that causes command-line variables to be passed as
command-line variables to sub-processes that make(1) executes
broke it. By changing the type of all DESTDIR variables used
internally in Makefile.inc1, from environment to command-line
variables of the highest priority, I was able to "make world"
with success, with the command-line variable DESTDIR set.
determines which CVS tag to track when running make update. This makes
it easier to configure a box to track a particular release if it does
automated updates from a cvs repository.
in rev. 1.57. Fix this regression by making cc_tools a new-style
build-tool in Makefile.inc1. For details of what has been fixed,
please see the gnu/usr.bin/cc/cc_tools/Makefile,v 1.52 commit log.
Caught this by accidentally touching param.h while in the process
of cross-buildworld for amd64.
only, and not as a global (in /etc/make.conf) or command-line variable.
MAKEOBJDIRPREFIX has never been a global or command-line variable, and
the fact that it works in some scenarios for "make buildworld" doesn't
make it any more correct. Using it as a global or command-line variable
is error prone, discouraged, costs us lot of false build reports, etc.
This commit is aimed to fix it once and for all.
Anyone potentially objecting to this change is encouraged to read the
make(1) and make.conf(5) manpages, and the comments regarding the use
of the MAKEOBJDIRPREFIX variable in /usr/share/mk/bsd.obj.mk and
/usr/share/examples/etc/make.conf.
two -n flags. If only one -n flag is given the old behaviour
is retained (POLA). In order to make this working for installworld
change the IMAKEENV in this case so that the tools are found
(we have no temporary installation environment in this case).
Submitted by: ru (IMAKEENV part)
help some ports that depend on libradius that recently gained
the dependency on libssl. This is also how the stock OpenSSL
build would link libssl.so on FreeBSD.
Prompted by: kris
OK'ed by: markm, nectar
