From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3685 invoked by alias); 1 Apr 2002 22:02:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3678 invoked from network); 1 Apr 2002 22:02:12 -0000 Received: from unknown (HELO nerodeguest) (24.161.107.98) by sources.redhat.com with SMTP; 1 Apr 2002 22:02:12 -0000 Received: from neroden (helo=localhost) by nerodeguest with local-esmtp (Exim 3.35 #1 (Debian)) id 16s9sP-00027j-00; Mon, 01 Apr 2002 17:02:09 -0500 Date: Mon, 01 Apr 2002 14:02:00 -0000 From: Nathanael Nerode X-Sender: neroden@nerodeguest To: Alexandre Oliva cc: mike stump , gcc@gcc.gnu.org Subject: Re: autoconfiscation -- questions about make usage In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00013.txt.bz2 On 30 Jan 2002, Alexandre Oliva wrote: > On Jan 30, 2002, Nathanael Nerode wrote: > > This means I am probably going to be writing a small program to > > automatically generate Makefile.in, because there will be huge > > lists of almost identical targets (which could be collapsed with pattern > > rules, but not suffix rules). > > Care to explain in advance what kind of targets you're thinking of > generating? Perhaps we could help save you some work, should someone > think of a way to do it without needing such a program. Sorry, I finally got around to this. Here's more information than you asked for. The repetitive targets are entirely due to one thing: causing the subconfigures to be invoked by the Makefile rather than the top-level configure. (This is a feature which was requested by someone. It's also the easiest way to do things as long as AC_CONFIG_SUBDIR is broken, which it is in autoconf 2.13) First of all, the existing all-$(subdir) targets would have a new dependency configure-$(subdir). (if expanded, they'd look like this: all-misc: configure-misc cd misc; $(MAKE) all check-misc: configure-misc cd misc; $(MAKE) check ) And now the new repetitive targets: (Note that srcdir_abs is a version of srcdir which will be accurate when in the subdirectory -- has to be constructed by configure) (subconfigure_args are the arguments which should be passed to subconfigures -- must be set by configure) configure-misc: misc/Makefile misc/Makefile: config.status cd misc; ${srcdir_abs}/misc/configure ${subconfigure_args} This combination will force misc to be reconfigured precisely when the top level has been reconfigured. When something else has changed *within* the misc directory, the Makefile in the misc directory will deal with any problems. I think this is a moderately elegant piece of glue code. It depends on misc/Makefile being a *real* target, however. It can probably be converted into a single Makefile entry rather than one per subdirectory by (ab)use of macros, much like the other entries in Makefile.in. I'd rather not do this as it makes the code much more unreadable, and significantly slower. (If I had my way, much of the nonsense in the existing targets would also go away in favor of a more explicit Makefile.) But if I *did* do this, I'd run into a subtler problem: the current targets handle missing subdirectories by checking inside the make code and only doing stuff if the subdirectory is present. The use of the real target misc/Makefile makes this impossible. The 'missing directory' checks can be moved configure-side. Putting them configure-side essentially solves this problem -- at the expense of requiring 'configure' to take the list of subdirectories, and generate the lists of 'all-subdir' targets, 'check-subdir' targets, 'configure-subdir' targets, 'subdir/Makefile' targets, and so on. Using 'sed' or large shell loops. This should, in fact, work without requiring an additional 'stage'. But it leaves the slow, unreadable shell script fragments in the Makefile.in, and adds two more (!). And it's incredibly wasteful to use the list of subdirectories in the configure to generate several lists of targets, and then in each target to jump through hoops to get the original subdirectory name back. And this ends up moving some logic which belongs in the Makefile (such as which targets support 'check') out of the Makefile into configure. All of these disgusting things could be avoided: * trivially with (implicit) pattern rules (as opposed to suffix rules) * almost trivially with gcc's static pattern rules * with an appropriate set of new automake rules (I haven't worked out precisely how to write them, since I don't yet grok automake) * with a Makefile preprocessor which converted static pattern rules (with non-wildcard targets) into individual rules Moving the non-existent-directory checks into configure may (or may not) be a good idea anyway. If you think it's a good idea anyway, then the asterisked items above would still speed up the Makefile and make it much more readable, although they wouldn't avoid the heavy string-munging in configure. --Nathanael Nerode