From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15118 invoked by alias); 28 Dec 2002 20:26:25 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15094 invoked from network); 28 Dec 2002 20:26:24 -0000 Received: from unknown (HELO lacrosse.corp.redhat.com) (66.187.233.200) by 209.249.29.67 with SMTP; 28 Dec 2002 20:26:24 -0000 Received: from free.redhat.lsd.ic.unicamp.br (aoliva2.cipe.redhat.com [10.0.1.156]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id gBSKQ6Y09583; Sat, 28 Dec 2002 15:26:06 -0500 Received: from free.redhat.lsd.ic.unicamp.br (localhost.localdomain [127.0.0.1]) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6) with ESMTP id gBSKQ5MK027414; Sat, 28 Dec 2002 18:26:05 -0200 Received: (from aoliva@localhost) by free.redhat.lsd.ic.unicamp.br (8.12.6/8.12.6/Submit) id gBSKQ4eR027333; Sat, 28 Dec 2002 18:26:04 -0200 To: DJ Delorie Cc: drow@mvista.com, gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: (toplevel) Fix dramatic breakage for ordinary crosses (related to program_transform_name) References: <20021228093127.GA455@doctormoo> <20021228163419.GA10686@nevyn.them.org> <20021228175919.GA17177@nevyn.them.org> <20021228185007.GA22186@nevyn.them.org> <200212281859.gBSIxap07606@envy.delorie.com> From: Alexandre Oliva Organization: GCC Team, Red Hat Date: Sat, 28 Dec 2002 12:57:00 -0000 In-Reply-To: <200212281859.gBSIxap07606@envy.delorie.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-12/txt/msg00735.txt.bz2 On Dec 28, 2002, DJ Delorie wrote: > Not just update, but *merge*. Autoconf reads the cache, does lots of > processing, then writes the cache. The cache may have been updated > during the processing, and you don't want to toss those updates. Why not? It's just a cache, after all! Worst case, when you reconfigure, you get to rerun some tests. So what? Also, I've been measuring the size of config.cache in typical configurations, and I find it to always be about 20Kb for a full uberbaum build. The way autoconf updates it is to create a file named confcache, with the new contents of the cache, and then runs `cat confcache > $cache_file'. I believe it is safe to assume that writes that are this small are atomic on any reasonable OS, and the window for two or more simultaneous configure scripts to truncate the file at the same time, and then get a larger write() to complete faster than a smaller one, such that the smaller write doesn't completely overwrite the contents of the larger one, is so small that it's negligible. Just consider that updating config.cache is something that happens, what, at most 200 times in a full build, with a failure window that lasts a few microseconds in a process that can take about an hour. I'm not disputing that it can possibly fail. I just think the odds are so low that it's not worth worrying about. I'd at least like to be able to control this behavior with configure options. I'm working on something that will require configure options to disable the serialized configurations, but more and more I think we might as well turn them on by default. It's not like make -j is default or anything, and whoever uses make -j might also be expected to configure with an option that makes the build 100% -j-safe. > But it would be nice if autoconf managed this problem for us. It can't. Consider that the config.cache file specified in the command line may be in a directory that is not writable, and that two totally unrelated builds may be using the same config.cache file. How could autoconf possibly synchronize them so as to not get in trouble? To add to the fun, assume that the two configures are running in separate machines, whose only shared filesystem is the one containing config.cache, and such that there's no write permission on it anywhere except in the config.cache file. Of course, it *might* try to create a lock file in the directory containing config.cache (but then it might be a soft link elsewhere), but do you really want to be creating files all over the place that might be left dangling should the machine reboot? And then, consider that configure has really no way to tell something like --cache-file=/some/random/shared/config.cache from what it gets from the top-level Makefile, namely --cache-file=../../../config.cache (which might have been turned into a full, yet possibly non-canonical pathname such as --cache-file=`pwd`/config.cache). That said, using some autoconf 2.5x features, we may be able to come up with a configure-like script whose only purpose is to merge two config.cache files together, such that we could then try to be smarter and give each sub-package its own config.cache, just primed with the global cache and having the global cache updated (mostly)atomically afterwards. I say mostly because, if there are other, unrelated builds using the same global cache file, there's really nothing we can do to prevent them from conflicting. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer