From owner-svn-src-head@FreeBSD.ORG Sat Oct 16 08:07:55 2010 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F02E106566C; Sat, 16 Oct 2010 08:07:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 35AB68FC08; Sat, 16 Oct 2010 08:07:54 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o9G87piM060403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 16 Oct 2010 11:07:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id o9G87p1D026108; Sat, 16 Oct 2010 11:07:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o9G87pgG026107; Sat, 16 Oct 2010 11:07:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 16 Oct 2010 11:07:51 +0300 From: Kostik Belousov To: John Baldwin Message-ID: <20101016080751.GQ2392@deviant.kiev.zoral.com.ua> References: <201010141919.o9EJJJIc034032@svn.freebsd.org> <201010150845.22576.jhb@freebsd.org> <96F4E353-55A6-48E6-BA20-92720EC2C4E7@freebsd.org> <201010151628.41177.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AIVxJgaslCM/0U4c" Content-Disposition: inline In-Reply-To: <201010151628.41177.jhb@freebsd.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, Dimitry Andric , svn-src-all@freebsd.org, src-committers@freebsd.org, Rui Paulo Subject: Re: svn commit: r213845 - head/sys/dev/aic7xxx/aicasm X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Oct 2010 08:07:55 -0000 --AIVxJgaslCM/0U4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 15, 2010 at 04:28:40PM -0400, John Baldwin wrote: > On Friday, October 15, 2010 2:50:46 pm Rui Paulo wrote: > > On 15 Oct 2010, at 13:45, John Baldwin wrote: > >=20 > > > On Thursday, October 14, 2010 5:09:58 pm Dimitry Andric wrote: > > >> On 2010-10-14 21:39, John Baldwin wrote: > > >>> On Thursday, October 14, 2010 3:19:19 pm Rui Paulo wrote: > > >> ... > > >>>> Revert r213765. This is required because our build infrastructur= e uses > > >>>> the host lex instead of the lex built during buildworld. I will = MFC the > > >>>> lex changes soon and in a few weeks this I'll commit again r2137= 65. > > >>> Can't you make 'lex' a build-tool to workaround this? > > >>=20 > > >> That will not help for "cd conf/CONF && make kernel", apparently. It > > >> will always use the host lex. > > >=20 > > > Well, yes, but that is always true. build-tools are only used for > > > buildkernel. However, if an 8.x lex cannot build a 9.x kernel, then = having > > > lex be a build-tool (or cross-tool, ru@ knows which category better t= han I) > > > will let a 'make kernel-toolchain' followed by 'make buildkernel' of = a 9.x > > > source tree work on an 8.x host. > >=20 > > Yes, but I was told that 'cd conf/CONF && make kernel' is a supported c= onfiguration (without requiring kernel-toolchain first). >=20 > Nah, just when it happens to work. It's ok to require people to build a = new > world to get a new lex in that case. However, for the buildkernel case t= he > 'buildworld' / 'toolchain' / 'kernel-toolchain' targets should always bui= ld > enough tools to let buildkernel work, so if a new lex is required they sh= ould > build a new lex. If it does not cost too much to keep make kernel style of build working, then it should be kept. In this case, the only requirement is to merge lex changes to stable branches. This is what I suggested (or requested, depending on how you interpret my mood). The lex backporting is orthogonal to the issue whether the lex shall become build tool. --AIVxJgaslCM/0U4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAky5XVYACgkQC3+MBN1Mb4hpDACeNPOuAFZGGkY3/8UfC+VB489i BeQAnRPhxbaEW42GBY8iwW2sWn4gSHyu =2otL -----END PGP SIGNATURE----- --AIVxJgaslCM/0U4c--