summaryrefslogtreecommitdiffstats
path: root/Makefile.inc1
Commit message (Collapse)AuthorAgeFilesLines
* Add endianness support to cap_mkdb(1), useful for cross builds.ru2005-02-221-0/+5
|
* Add lorder(1) to the list of bootstrap-tools.ru2005-02-191-0/+1
|
* Allow to cross-build amd64 on non-i386.ru2005-02-191-1/+2
|
* In crunchgen(1), when calling make(1), don't redirect stderr to stdout,ru2005-01-201-1/+1
| | | | | | | just rely on the exit status to detect an error. This makes crunchgen(1) safe to use with certain make(1) debugging flags. MFC after: 1 week
* Remove the special sparc64 time_t support.obrien2004-12-291-51/+0
| | | | | If someone isn't running with a 64-bit time_t by now, they don't track -CURRENT and would probably go to RELENG_5 vs. 6-CURRENT.
* Further fix the case mentioned in rev. 1.302. Theru2004-12-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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".
* NOCLEAN -> NO_CLEANru2004-12-211-6/+6
| | | | NOCLEANDIR -> NO_CLEANDIR
* NOSHARE -> NO_SHAREru2004-12-211-3/+3
|
* NOHTML -> NO_HTMLru2004-12-211-3/+3
|
* NOGAMES -> NO_GAMESru2004-12-211-3/+3
|
* NOCRYPT -> NO_CRYPTru2004-12-211-11/+11
|
* NOSHARED -> NO_SHAREDru2004-12-211-1/+1
|
* NOFSCHG -> NO_FSCHGru2004-12-211-1/+1
|
* NODOCCOMPRESS -> NO_DOCCOMPRESSru2004-12-211-6/+6
| | | | | | | | NOINFO -> NO_INFO NOINFOCOMPRESS -> NO_INFOCOMPRESS NOLINT -> NO_LINT NOPIC -> NO_PIC NOPROFILE -> NO_PROFILE
* NOLIBC_R -> NO_LIBC_Rru2004-12-211-1/+1
| | | | | NOLIBPTHREAD -> NO_LIBPTHREAD NOLIBTHR -> NO_LIBTHR
* Start the dreaded NOFOO -> NO_FOO conversion.ru2004-12-211-4/+4
| | | | OK'ed by: core
* Minor tweaks in "make update" comments.ru2004-12-171-3/+3
|
* Do not leave build droppings in /usr/src for usr.sbin/pcvt/keycap andpeter2004-12-011-0/+4
| | | | | usr.bin/lex/lib for the 32 bit libraries on amd64. Add an explicit obj for these two directories that are built in for the "libraries" target.
* Hopefully fix the "aicasm" build-tool issue when using ${KERNSRCDIR}ru2004-11-231-1/+1
| | | | | | different from ${.CURDIR}. Reported by: jhb
* In the amd64 hybrid libraries case, move the kerberos5 tools to beforepeter2004-11-201-6/+6
| | | | | | 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!
* Oops, all my test boxes have NO_KERBEROS set, so I didn't hit the kerberos5peter2004-11-151-0/+10
| | | | | build tools problem. I'd missed the kerberos5/tools stuff entirely. Add the missing bits.
* Add knob NO_NIS (fka NO_YP_LIBC) and make world compileable when set.bz2004-11-131-1/+5
| | | | | | | | | | | 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
* Show stray files during "cvs update".ru2004-11-121-1/+1
|
* Ruslan told me I should have quoted the arch strings when comparing topeter2004-11-101-4/+4
| | | | MACHINE_ARCH. Belatedly get around to doing it.
* Change WANT_LIB32 to WITH_LIB32. Sorry for the whiplash folks.peter2004-11-101-2/+2
| | | | | | | 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.
* Convert tools/lib32/build.sh into world connectable hooks. This stillpeter2004-11-061-0/+93
| | | | | | | | | | | | 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.
* For variables that are only checked with defined(), don't provideru2004-10-241-1/+1
| | | | any fake value.
* Catch another gcc-3.3 c++ include path reference and update it to 3.4.peter2004-10-111-1/+1
|
* 1. Add much finer granularity to the NO_BIND knobs with the addition of:dougb2004-09-271-0/+4
| | | | | | | | | 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
* Hopefully fix alpha and sparc64 builds: on these architectures,ru2004-09-211-3/+4
| | | | | | | | | | 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
* Switch from BIND 8 to BIND 9.des2004-09-211-0/+7
| | | | | | Submitted by: (in part) dougb@, trhodes@ Reviewed by: dougb@, trhodes@, re@ MFC after: 5 days
* Although 'Unanimous Consent' appears to be a well defined and used inimp2004-09-071-9/+9
| | | | | | | | | | | | | | | 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
* Backout the CVSTAG variable, it could potentially be dangerous ifpaul2004-08-261-3/+0
| | | | | | you track multiple releases in different trees. Leave the CVSOPTIONS variable there since it could be useful.
* Fix "make world DESTDIR=/mnt" to work again. A recent changeru2004-08-251-4/+4
| | | | | | | | | 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.
* Add a CVSTAG makefile variable that can be set in /etc/make.conf thatpaul2004-08-241-1/+5
| | | | | | 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.
* A fix from rev. 1.52 of gnu/usr.bin/cc/cc_tools/Makefile was lostru2004-08-181-1/+1
| | | | | | | | | 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.
* Moved the MAKEOBJDIRPREFIX check from Makefile.inc1 to Makefile,ru2004-08-181-7/+0
| | | | | to suppress warnings with installworld and distributeworld when env(1) cannot be found in the PATH.
* sys/boot seems to compile fine on Alpha; unbreak ``make release''.ru2004-08-161-4/+1
| | | | Prodded by: re-alpha (wilko)
* Ensure that a new gensnmptree is built. This should fix the problemsharti2004-08-111-1/+1
| | | | with the snmp_atm module.
* Enforce the check that MAKEOBJDIRPREFIX (if set) is set in environmentru2004-08-111-0/+7
| | | | | | | | | | | | | | | | 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.
* Fix recent breakage in rescue. We need to build a new crunchgenharti2004-08-101-1/+1
| | | | | | that will not emit the bad MAKE=make line that caused the breakage. Submitted by: ru
* Make make recurse into sub-directories and sub-makes when givenharti2004-08-091-22/+27
| | | | | | | | | 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)
* The file(1) related build-tool moved to libmagic.obrien2004-08-091-1/+1
|
* Bmake glue for GCC 3.4.2-prerelease.kan2004-07-281-5/+0
|
* Get rid of the THISHOST variable when building on sparc64. The problemharti2004-07-081-5/+1
| | | | | with it is that it is set by calling hostname and hostname isn't normally in the path at that point.
* Third time's a charm?? (the logic was reversed from desired)obrien2004-06-171-1/+1
| | | | | | Time for sleep... Submitted by: ru
* Grrr, use the userland spelling not the kernel tree spelling.obrien2004-06-171-1/+1
|
* Fall out from Binutils 2.15: disable building the Alpha loader.obrien2004-06-171-1/+4
|
* Allow buildworld and friends to complete when make(1) is calledru2004-05-171-1/+1
| | | | | | with some debug flags (-d). Noticed by: Gleb Smirnoff
* Record the libssl.so dependency on libcrypto.so. This shouldru2004-05-131-0/+1
| | | | | | | | | 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
OpenPOWER on IntegriCloud