From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23358 invoked by alias); 2 May 2003 02:21:33 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 23340 invoked from network); 2 May 2003 02:21:33 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.172.59.41) by sources.redhat.com with SMTP; 2 May 2003 02:21:33 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 3538D354C; Thu, 1 May 2003 19:21:32 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id h422LVb08611; Thu, 1 May 2003 19:21:31 -0700 Date: Fri, 02 May 2003 02:21:00 -0000 Message-Id: <200305020221.h422LVb08611@magilla.sf.frob.com> From: Roland McGrath To: GNU libc hackers Subject: dependency generation changes X-windows: the defacto substandard. X-SW-Source: 2003-05/txt/msg00001.txt.bz2 I've just put in some makefile changes that revamp the way automatic dependencies are handled. There is no longer a separate dependency-generation pass. Instead, the compilations use -MD and related options to generate a dependency file corresponding to each object file. This means the dependencies are now right for all the different flavors of object file when things like #ifdef SHARED are involved. One oddity in how I did this is that the post-processing we do on dependency files is not done immediately after the compilation that generated the file, but by the next make run that uses it. I can change this if it proves to be a problem. The post-processing step allows the build directory to be relocated. After a "make" run, the dependency files generated during the "make others" pass will still be around in their un-post-processed form, and likewise with the test file deps after "make check". Any make run that completes without compiling anything new will post-process all the dependency files, so if you want to leave a build directory such that you can move it around later, do an extra "make". An important new caveat is that if you remove dependency files (*.d and *.dt) by hand without removing the corresponding object files, then the dependency information will be lost. Be careful not to do that, or a later header file change might not cause everything to be rebuilt that it should. I tested some builds from scratch and some using old build directories. I haven't done exhaustive testing. Please let me know if you see any new problems with the makefiles. It's hard to robustly test that all the right dependencies are there, i.e. that changing files causes recompilations when it should. I did only trivial testing of that. Thanks, Roland