From owner-freebsd-current@FreeBSD.ORG Wed Aug 11 22:54:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94B2916A4CE; Wed, 11 Aug 2004 22:54:03 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CE2943D48; Wed, 11 Aug 2004 22:54:03 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7BMqrVj097156; Wed, 11 Aug 2004 16:52:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 11 Aug 2004 16:53:03 -0600 (MDT) Message-Id: <20040811.165303.35850140.imp@bsdimp.com> To: ru@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040811224317.GE96867@ip.net.ua> References: <20040811221348.GB93983@ip.net.ua> <20040811.162640.00482545.imp@bsdimp.com> <20040811224317.GE96867@ip.net.ua> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: harti@freebsd.org cc: current@freebsd.org cc: kris@obsecurity.org Subject: Re: World broken in stage 1.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2004 22:54:03 -0000 In message: <20040811224317.GE96867@ip.net.ua> Ruslan Ermilov writes: : On Wed, Aug 11, 2004 at 04:26:40PM -0600, M. Warner Losh wrote: : > In message: <20040811221348.GB93983@ip.net.ua> : > Ruslan Ermilov writes: : > : On Wed, Aug 11, 2004 at 04:04:20PM -0600, M. Warner Losh wrote: : > : > In message: <20040810231044.GA70020@xor.obsecurity.org> : > : > Kris Kennaway writes: : > : > : More fallout from the wonderful new make(1) semantics? : > : > : > : > I think it is speficially related to the changes to src/Makefile and : > : > src/Makefile.inc1. If I s/${_+_}//g on those two files, it appears : > : > that I can buildworld again (at least it doesn't die right away). : > : > : > : How exactly does it die for you, please provide some logs. : > : > The problem is due to the following in share/mk/sys.mk: : > : > .if !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" : > _+_ ?= : > .else : > _+_ ?= + : > .endif : > : > This should have a third clause: : > : > .if ${MAKE_VERSION} >= 5200408030 && !empty(.MAKEFLAGS:M-n) && ${.MAKEFLAGS:M-n} == "-n" : > : > so that _+_ is defined to be nothing for those versions of make that : > don't yet support this new feature of posix. : > : Why? It's not supposed that you try an old make(1) binary with : the new share/mk/sys.mk. src/Makefile will upgrade make(1) if : necessary, then use it (or the old make if it's adequate) with : new share/mk stuff to call Makefile.inc1. If you throw away : the -m from your "make" command in your build script, it will : work. I'm not entirely sure why we have it in our build scripts. My software archiology is such that I can't find out why this was added to them (because the same code has jumped between N tools that have grown up over the years). : We want to be able to use the new make(1) features in our : share/mk files right after when they made available. That was : one of the main ideas of the make(1) regression testing feature : in src/Makefile. OK. : It's like we now handle backward issues in our C sources -- we : agreed not to pollute sources with __FreeBSD_version checks, : and we keep the necessary bootstrapping glue in a separate : place. The same applies here -- one is free to use new make(1) : features in src/ makefiles and in share/mk support files. : src/Makefile and tools/regression/usr.bin/make guarantee that : we'll always use the make(1) binary compatible with the : feature set used in our .mk and makefiles. OK. : Please update your build scripts... These build scripts have been this way since the product that used FreeBSD 3.4.1... This is the first time that there has been a problem with that :-(. I'll try to update and fixed like you suggested, however... Warner