From owner-freebsd-current@FreeBSD.ORG Fri Dec 2 06:22:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org 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 42A7E16A41F; Fri, 2 Dec 2005 06:22:28 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9B6F43D58; Fri, 2 Dec 2005 06:22:24 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000034373.msg; Fri, 02 Dec 2005 12:22:19 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 129826, updated: 2.12.2005] To: freebsd-current@freebsd.org References: <1133397567.40645.5.camel@WarHeaD.OTEL.net> <20051201053543.GC36718@ip.net.ua> <1133436603.37980.9.camel@DraGoN.OTEL.net> <20051201175639.GH32006@cirb503493.alcatel.com.au> <20051201184703.GK20961@ip.net.ua> From: Victor Snezhko Date: Fri, 02 Dec 2005 12:22:17 +0600 In-Reply-To: <20051201184703.GK20961@ip.net.ua> (Ruslan Ermilov's message of "Thu, 1 Dec 2005 20:47:03 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Fri, 02 Dec 2005 12:22:19 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-VVS-Spam: false Cc: Subject: Re: 6.0-STABLE buildworld (possibly) broken ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 02 Dec 2005 06:22:28 -0000 Ruslan Ermilov writes: >> This problem seems to come up fairly regularly. How about adding a >> check into make(1) so that if a dependency has a date in the future, >> make dies with more intuitive error? It would probably reduce the >> number of these questions if you got an error message like: >> "foo.c was created in the future. Check your system date/time." >> >> IMHO, that's a lot more obvious than: >> "/usr/obj/usr/src/tmp/usr/bin/ld: cannot find -lc" >> or >> "... touch not found ..." >> > I considered doing this in make(1) a while ago, but have come > to a conclusion it's not quite safe. For example, I often > "cvs update" from remote repositories, and that sets modification > time to that of the repository machine (probably only if it's a > new file, I don't recall all the conditions now, or it might > have been NFS-mounted src/ or repo). We could add a flag such as NO_TIME_CHECK or so and check only if the flag isn't set. -- WBR, Victor V. Snezhko EMail: snezhko@indorsoft.ru