From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1627 invoked by alias); 20 Dec 2002 01:18:55 -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 1520 invoked from network); 20 Dec 2002 01:18:52 -0000 Received: from unknown (HELO mailout6-0.nyroc.rr.com) (24.92.226.177) by 209.249.29.67 with SMTP; 20 Dec 2002 01:18:52 -0000 Received: from doctormoo (syr-24-24-16-193.twcny.rr.com [24.24.16.193]) by mailout6-0.nyroc.rr.com (8.11.6/RoadRunner 1.20) with ESMTP id gBK1IQk27827; Thu, 19 Dec 2002 20:18:26 -0500 (EST) Received: from neroden by doctormoo with local (Exim 3.36 #1 (Debian)) id 18PBmv-0000QD-00; Thu, 19 Dec 2002 20:17:17 -0500 Date: Thu, 19 Dec 2002 17:29:00 -0000 To: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com, binutils@sources.redhat.com Subject: Re: (toplevel patch) Fix multilib.out dependencies and related problems Message-ID: <20021220011716.GA1569@doctormoo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i From: Nathanael Nerode X-SW-Source: 2002-12/txt/msg00567.txt.bz2 I said: > Removed xgcc and ran 'make'; gcc rebuilt it, and target libs were > reconfigured and built. DJ quoth: >That shouldn't happen. Use move-if-change to update one common >multilib.out, so that if the list of multilibs doesn't change, >*nothing* gets reconfigured or rebuilt. We want to trigger a *check* >when gcc changes, but only actually *reconfigure* if needed. Uh, yeah. Make isn't designed to realize that you can change a file and not change the generated file depending on it; this is not an unreasonable assumption in most cases. To put it another way, I don't care very much. >I'm wondering if the common multilib.out target should depend on the >all-gcc phony target; we kinda want it to run every time we check the Of course it should. But it can't, it actually can't, because then we have a real target depending on a phony target, and every target subdir gets reconfigured every single time. Sorry. You could try to do this with a phony multilib.out target. Then you'd need to make configure-target-foo depend on it instead of (TARGET_SUBDIR)/foo/Makefile. And you'd find that target subdirs would never get reconfigured. Sorry. You could patch that problem up by putting the code for foo/Makefile back into configure-target-foo, and hard-coding yet more things Make should do, such as determining whether foo/Makefile is out of date. Maybe this is the preferred method, but I will have nothing to do with it, since I'm certain it's the wrong direction to go. >gcc subdir, because we don't know if something else besides xgcc >affects the specs (which affects multilib.out). Eeech. We should actually know what affects the specs, you know. :-/ > We can get away with >this if we use move-if-change. Kinda, sorta. Here's a scheme, which might do the trick. (First note that a common multilib.out is a separate issue and can and should be done however we fix these other things.) Have the common multilib.out depend on nothing. Have the build process for gcc (I hope there's nothing else which can affect multilib.out...) do the testing and move-if-changing of multilib.out. Effectively, this is a preinstall; building all-gcc should build multilib.out directly into the location where the target subdirs look for it, and the rules for regenerating it will live in the gcc Makefile. This should mean that a change in gcc, provided the build process is used, will change multilib.out. Happy with this? If not, here are some other ideas, thrown out at least partly in frustration: * Whatever determines the contents of multilib.out should just get its own damn rule at the top level, rather than messing around with building the whole of gcc to determine that it's ".;". * Force every target subdir which actually cares about this to produce its own copy of multilib.out and to test whether it's out of date on its own, so that it's out of the hair of the top level. * Don't support toplevel Make at all. * Convert the configuration and Makefiles for all subdirectories to fragmentary Makefile fragments, which are plugged into the top level. In other words, only support the top level. * Make all-gcc a real target, similarly for all the others, and require the subdirs to create the corresponding files name 'all'. This is actually a pretty good idea, although it's quite non-standard; it amounts to the total elimination of all phony targets. * Use existing real targets: in place of all-gcc, use gcc/xgcc gcc/cc1 etc. This of course requires massive and ugly changes to the top level. -- Incidentally, I now know the one feature I want added to all versions of Make, and it's not one which exists in any version of make I've seen. Plus, it's very very simple. For any target, in addition to being able to specify a command and dependencies, you should be able to specify an external program to run in a shell, which gives exit status 0 if the target is up to date and exit status 1 if the target needs to be rebuilt. (For total generality, it might require a shell variable to be passed in indicating whether the dependencies were up to date.) If it returned 1, the dependencies would still have to be examined to see if they needed to be rebuilt first, however. This would deal with virtually all "problems" with Make in a generic way. For instance, we simply annotate multilib.out with its test and a dependency on all-gcc. All-gcc is still considered updated every time, but this doesn't force multilib.out to be. This actually solves every real issue I have ever seen anyone have with Make ever, and I am surprised that it hasn't been implemented in any version I've met. I'm not sure which make variants to push this idea at... --Nathanael