From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2591 invoked by alias); 12 Jul 2011 20:43:06 -0000 Received: (qmail 2572 invoked by uid 22791); 12 Jul 2011 20:43:04 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-iw0-f169.google.com (HELO mail-iw0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jul 2011 20:42:18 +0000 Received: by iwn8 with SMTP id 8so5812614iwn.0 for ; Tue, 12 Jul 2011 13:42:17 -0700 (PDT) Received: by 10.42.39.18 with SMTP id f18mr317271ice.281.1310503337167; Tue, 12 Jul 2011 13:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.213.134 with HTTP; Tue, 12 Jul 2011 13:41:57 -0700 (PDT) In-Reply-To: References: <1310436152-8693-1-git-send-email-vapier__46811.2245122485$1310436164$gmane$org@gentoo.org> From: Mike Frysinger Date: Tue, 12 Jul 2011 20:59:00 -0000 Message-ID: Subject: Re: [PATCH] sim: generate build dependencies on the fly To: Tom Tromey Cc: gdb-patches@sourceware.org, toolchain-devel@blackfin.uclinux.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-07/txt/msg00323.txt.bz2 On Tue, Jul 12, 2011 at 15:48, Tom Tromey wrote: >>>>>> "Mike" =3D=3D Mike Frysinger writes: > Mike> Generated header files still need to be manually tracked. > > Why is that? it didnt seem to work :). if the dependency generation step is done inline with the compile step, how can we figure out the dependency info of a header file that is generated ? does gdb handle this and i just missed it in its Makefile ? a good example is the mn10300 subdir (which coincidentally, i'm pretty sure is already missing dependency info and often fails to build in parallel today). the "sim-main.h" header is included by pretty much all sim files and each arch must create it. mn10300's sim-main.h relies on the generated headers "itable.h" and "idecode.h" which come from running ../igen/igen. so they add those headers to SIM_EXTRA_DEPS as most objects will depend on the files in that existing. > Mike> -VPATH =3D @srcdir@ > Mike> +VPATH =3D @srcdir@:$(srccom) > > The Autoconf manual lists various problems with VPATH. > > You can't use variable references in VPATH. i read some info on that, but it sounded like the known issues were worked around by configure. such as empty vpath and "." entries. but i guess i didnt delve into the autoconf manual to double check. > Also VPATH won't work properly with built sources. =A0I'm not sure if your > patch relies on that or not. the common subdir does generate one "sim-inline.c" file for a few targets. seemed to generate/build on my system, but i'm using up-to-date GNU make, so that probably doesnt count. > Finally I thought there was some problem with multiple entries in VPATH, > but I cannot find that in the docs. =A0Perhaps it is one of those ancient > incorrect memories. =A0It would bear testing with a non-GNU make. sounds like all good reasons to use automake :). otherwise all the files in common/ need manual deps (like gdb does with files in subdirs), and that semi-defeats the purpose of this in the first place. > Mike> +depcomp =3D $(SHELL) $(srcdir)/../depcomp > > This seems like the wrong directory to me. > I would have expected $(srcdir)/../../depcomp. yeah ... i didnt notice as my stuff all went through gcc for dep info. probably better to use $(srcroot)/depcomp. -mike