From owner-freebsd-current@freebsd.org Fri Jul 24 00:55:04 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B56819A9D21; Fri, 24 Jul 2015 00:55:04 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 779051A08; Fri, 24 Jul 2015 00:55:04 +0000 (UTC) (envelope-from jbtakk@iherebuywisely.com) Received: from [10.9.9.241] (helo=rmm6prod02.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1ZIRGJ-0004Fc-Bp; Fri, 24 Jul 2015 02:54:55 +0200 Received: from mail by rmm6prod02.runbox.com with local (Exim 4.76) (envelope-from ) id 1ZIRGI-00015B-Ul; Fri, 24 Jul 2015 02:54:54 +0200 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [Authenticated user (846156)] by runbox.com with http (RMM6); Fri, 24 Jul 2015 00:54:54 GMT From: "Jeffrey Bouquet" Reply-To: jbtakk@iherebuywisely.com To: "current" CC: "freebsd-current" Subject: Re: "proper way" or "unworkable idea" ? > [SOLVED] Date: Thu, 23 Jul 2015 17:54:54 -0700 (PDT) X-Mailer: RMM6 In-Reply-To: <5592E5CF.6020509@digiware.nl> Message-Id: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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: Fri, 24 Jul 2015 00:55:04 -0000 On Tue, 30 Jun 2015 20:54:07 +0200, Willem Jan Withagen w= rote: > On 30/06/2015 17:32, Simon J. Gerraty wrote: > > Jeffrey Bouquet wrote: > >=20 > >> If I've a spare /mnt/usr/src , it seems buildworld quite soon fails, > >> where it otherwise may succeed in /usr/src. Any CLI parameters or> the > >> build system is hardcoded enough so that there will always be > >> problems? > >=20 > > The only thing hard coded is the default MAKEOBJDIRPREFIX (it isn't > > called that but it works the same way), but even that should work for a= ny > > location. I always have MAKEOBJDIRPREFIX when doing buildworld etc, > > and have never used /usr/src. > >=20 > > Is there perhaps something interesting about /mnt/usr/src (like > > ancient?) >=20 > On some of the systems where I use different versions, I have > /usr/srcs > mounted of the NFS-server. in which I have. > /usr/srcs/src8/src > /usr/srcs/src9/src > /usr/srcs/src10/src > /usr/srcs/head/src >=20 > Then also have /usr/objs mounted, with the same setup >=20 > And on the remote systems link /usr/src -> /usr/srcs/src??/src and same > for obj.... >=20 > I have yet to run into trouble when I do the normal things. It gets > messy if I'd like to build both i386 and amd64 in the same obj-tree. > That does not always work, but adding a differentiating i386 and amd64 > to the hierarchy seemed to fix it. But I retired all but one i386, and > that is soon to follow. >=20 > --WjW >=20 >=20 >=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Using a r285418 (july 12), rsynced /usr/obj and /usr/src ( precise howto found in the motd where I store stuff... cp -Rp that is)=20 # cp -Rp /mnt_usr/obj/usr/src /usr/obj/usr # /usr as a seperate filesystem ... note 4 > 3 # cp -Rp /mnt_usr/src /usr # /usr as a seperate filesys= tem ... note 2 > 1=20 the MAKEOBJDIRPREFIX seems to be working for the first time ever. Cntl-c'd= it since the installkernel/installworld did the upgrade... so something was fixed. = Could probably comtinue with the MAKEOBJDIRPREFIX buildworld if I was sure (doubly sure)= =20 how to install from the "different" location to the "usual" one... without a hitch. So that m= ay come later this year... unless something else breaks the specific build environment which c= aused this thread, which appears SOLVED...=