Date: Wed, 11 Sep 1996 09:33:14 -0500 From: rkw@dataplex.net (Richard Wackerbarth) To: "Julian H. Stacey" <jhs@freebsd.org> Cc: current@freebsd.org Subject: Re: Latest Current build failure Message-ID: <v02140b02ae5c739acbe8@[208.2.87.4]>
next in thread | raw e-mail | index | archive | help
"Julian H. Stacey" <jhs@freebsd.org> writes: >We currently have no `builds OK' token at all, >as such, anything's better than nothing :-) >so define your token as rigorously or laxly as you feel, IMHO, it , de facto, sets a minimum standard for the developers. >in my (personal) book, if you put in the work, you get to decide, >without hinderance of a thousand discordant other opinions, >later when it goes public it can always be changed Unfortunately, it requires that I change the present Makefiles because they don't stand a chance of working in their present form. (Recursive "definition" of Makefile behavior) Since I haven't gotten Jordan, et al to agree to either 1) Freeze the makefiles until I have a chance to make a working set or, preferably, 2) agree to a different modus operandi whereby we decide on a design and then collectively, or perhaps individually, without others running counter to that design implement it, I do not feel that I can reasonably reach the desirable goal of being able to build a "current" system in an automated manner, starting only with a 2.1.5 system. As much as I hate it, since I have lots of HD space, I can clone my entire system and run in a chroot environment in order to avoid trashing my production environment. However, that does not address the recursive bootstrap problem which can be solved only by unrolling things and making the initial primitive steps so that they do not rely on the "enhanced" features of the version of "make" which is in current. Such a change affects (IMHO, too) many sections of the makefiles.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v02140b02ae5c739acbe8>