Message ID | 867ewtbxwb.fsf@gmail.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 125141 invoked by alias); 20 Sep 2017 08:04:27 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 124041 invoked by uid 89); 20 Sep 2017 08:02:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:static. X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 20 Sep 2017 08:02:51 +0000 Received: by mail-wm0-f42.google.com with SMTP id 13so4739268wmq.2 for <gdb-patches@sourceware.org>; Wed, 20 Sep 2017 01:02:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=eZ4uusfxnqTtA2xcnKd48YApCpqj5q7Z08oN/JnA4os=; b=HIavVn1PRvzS9pZw17I+TubcwxVasnXHCbpNMB2Vh5fx1/gDGqwYI+h9ejXwDb/Ic3 yJgYEbUWMfENKf5TTo/cEe0HUTHBuu/AXyEi72HRijyp3T6WbPJkUks9HIATlY6hDSvX Qodv+bpxHdHDAQ8dvoxQc2WBnx9q9yNHITwIQtFKi4DUQh8GWMa2+3DvkwAJKMQSLXUW o6udzYateeddgvCM1frhvV8lQWJ9fo+fdyEvKR0u1i90AO1hNqd/2NGFX2tzK4bc7kZ3 yRb7t+/gy7yCKQuxKev/RG9YVKCeO5On1Zk/2VPrXOQiDG0IQ+iKF9CmHD/P3mUlvThK RoxQ== X-Gm-Message-State: AHPjjUjHV0WEy7u+HQN14pq8DpiYES88eYJprBQzNRwEB/4e2O1swrLx A6pdMV9V6tXCX/rBB8p8wKHNGw== X-Google-Smtp-Source: AOwi7QCqIk56nTwiowLYK6pOWp6q+4kNf0WYa2mQFvfoqQmxxdETaKUN49pKMZ8s5wnpPQPJfS6AqA== X-Received: by 10.28.61.139 with SMTP id k133mr2933919wma.84.1505894568962; Wed, 20 Sep 2017 01:02:48 -0700 (PDT) Received: from E107787-LIN (static.42.136.251.148.clients.your-server.de. [148.251.136.42]) by smtp.gmail.com with ESMTPSA id h29sm1118637wrf.76.2017.09.20.01.02.47 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Wed, 20 Sep 2017 01:02:48 -0700 (PDT) From: Yao Qi <qiyaoltc@gmail.com> To: Simon Marchi <simon.marchi@polymtl.ca> Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Replicate src dir in build dir References: <1505832159-23038-1-git-send-email-yao.qi@linaro.org> <a200401d268672770bda464f3bc32383@polymtl.ca> Date: Wed, 20 Sep 2017 09:02:44 +0100 In-Reply-To: <a200401d268672770bda464f3bc32383@polymtl.ca> (Simon Marchi's message of "Tue, 19 Sep 2017 22:44:04 +0200") Message-ID: <867ewtbxwb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes |
Commit Message
Yao Qi
Sept. 20, 2017, 8:02 a.m. UTC
Simon Marchi <simon.marchi@polymtl.ca> writes: > I'm always a bit uncomfortable with putting some rm -rf commands in > scripts, if we can avoid it. Can we replace that with rmdir, since > the clean target should have emptied that directory just before? > > Also I wouldn't silence the commands (the @), it's always good to be > able to read what's being executed. > OK, I'll change to rmdir and remove @. >> >> maintainer-clean: local-maintainer-clean do-maintainer-clean distclean >> realclean: maintainer-clean >> @@ -2941,9 +2949,9 @@ ifeq ($(DEPMODE),depmode=gcc3) >> # into place if the compile succeeds. We need this because gcc does >> # not atomically write the dependency output file. >> override COMPILE.post = -c -o $@ -MT $@ -MMD -MP \ >> - -MF $(DEPDIR)/$(basename $(@F)).Tpo >> -override POSTCOMPILE = @mv $(DEPDIR)/$(basename $(@F)).Tpo \ >> - $(DEPDIR)/$(basename $(@F)).Po >> + -MF $(@D)/$(DEPDIR)/$(@F).Tpo >> +override POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(@F).Tpo \ >> + $(@D)/$(DEPDIR)/$(@F).Po >> else >> override COMPILE.pre = source='$<' object='$@' libtool=no \ >> DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC) > > I have never tested it, but I assume the "depcomp" mode of dependency > management will have to be updated too. I don't understand this comment. The only change in on dependency tracking is that .Po file is moved to a new place (.deps/amd64.Po -> ./arch/.deps/amd64.o.Po). The file contents don't change. $ diff -u .deps/amd64.Po ./arch/.deps/amd64.o.Po
Comments
On 2017-09-20 10:02, Yao Qi wrote: >>> @@ -2941,9 +2949,9 @@ ifeq ($(DEPMODE),depmode=gcc3) >>> # into place if the compile succeeds. We need this because gcc does >>> # not atomically write the dependency output file. >>> override COMPILE.post = -c -o $@ -MT $@ -MMD -MP \ >>> - -MF $(DEPDIR)/$(basename $(@F)).Tpo >>> -override POSTCOMPILE = @mv $(DEPDIR)/$(basename $(@F)).Tpo \ >>> - $(DEPDIR)/$(basename $(@F)).Po >>> + -MF $(@D)/$(DEPDIR)/$(@F).Tpo >>> +override POSTCOMPILE = @mv $(@D)/$(DEPDIR)/$(@F).Tpo \ >>> + $(@D)/$(DEPDIR)/$(@F).Po >>> else >>> override COMPILE.pre = source='$<' object='$@' libtool=no \ >>> DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC) >> >> I have never tested it, but I assume the "depcomp" mode of dependency >> management will have to be updated too. > > I don't understand this comment. The only change in on dependency > tracking is that .Po file is moved to a new place (.deps/amd64.Po -> > ./arch/.deps/amd64.o.Po). The file contents don't change. > > $ diff -u .deps/amd64.Po ./arch/.deps/amd64.o.Po > --- .deps/amd64.Po 2017-09-20 07:57:04.903381133 +0000 > +++ ./arch/.deps/amd64.o.Po 2017-09-20 07:40:35.995718460 +0000 > @@ -1,4 +1,4 @@ > -amd64.o: ../../binutils-gdb/gdb/arch/amd64.c \ > +arch/amd64.o: ../../binutils-gdb/gdb/arch/amd64.c \ > ../../binutils-gdb/gdb/arch/amd64.h > ../../binutils-gdb/gdb/arch/tdesc.h \ > build-gnulib/import/stdint.h > ../../binutils-gdb/gdb/common/x86-xstate.h \ > build-gnulib/import/stdlib.h \ I was wondering if this line needed changing override COMPILE.pre = source='$<' object='$@' libtool=no \ DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC) In particular, is DEPDIR treated as relative to the created object file or relative to the current working directory by depcomp. I honestly don't even know when this actually used. Simon
Simon Marchi <simon.marchi@polymtl.ca> writes: > I was wondering if this line needed changing > > override COMPILE.pre = source='$<' object='$@' libtool=no \ > DEPDIR=$(DEPDIR) $(DEPMODE) $(depcomp) $(CC) > > In particular, is DEPDIR treated as relative to the created object > file or relative to the current working directory by depcomp. I > honestly don't even know when this actually used. depcomp has already taken care of it, # Dependencies for sub/bar.o or sub/bar.obj go into sub/.deps/bar.Po. I hack Makefile, to set "depmode=gcc", # Dependency tracking information. DEPMODE = depmode=gcc and "make arch/amd64.o", source='../../binutils-gdb/gdb/arch/amd64.c' object='arch/amd64.o' libtool=no DEPDIR=.deps depmode=gcc /bin/bash ../../binutils-gdb/gdb/../depcomp g++ -x c++ -std=gnu++11 -g -O2 -I. -I../../binutils-gdb/gdb -I../../binutils-gdb/gdb/common -I../../binutils-gdb/gdb/config -DLOCALEDIR="\"/usr/local/share/locale\"" -DHAVE_CONFIG_H -I../../binutils-gdb/gdb/../include/opcode -I../../binutils-gdb/gdb/../opcodes/.. -I../../binutils-gdb/gdb/../readline/.. -I../../binutils-gdb/gdb/../zlib -I../bfd -I../../binutils-gdb/gdb/../bfd -I../../binutils-gdb/gdb/../include -I../libdecnumber -I../../binutils-gdb/gdb/../libdecnumber -I../../binutils-gdb/gdb/gnulib/import -Ibuild-gnulib/import -DTUI=1 -pthread -I/usr/include/guile/2.0 -I/usr/include/python2.7 -I/usr/include/python2.7 -Wall -Wpointer-arith -Wno-unused -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts -Wempty-body -Wunused-but-set-parameter -Wunused-but-set-variable -Wno-sign-compare -Wno-narrowing -Wno-error=maybe-uninitialized -Wformat-nonliteral -Werror -c -o arch/amd64.o ../../binutils-gdb/gdb/arch/amd64.c and the dependency file is generated in arch/.deps/amd64.Po, which looks right to me.
--- .deps/amd64.Po 2017-09-20 07:57:04.903381133 +0000 +++ ./arch/.deps/amd64.o.Po 2017-09-20 07:40:35.995718460 +0000 @@ -1,4 +1,4 @@ -amd64.o: ../../binutils-gdb/gdb/arch/amd64.c \ +arch/amd64.o: ../../binutils-gdb/gdb/arch/amd64.c \ ../../binutils-gdb/gdb/arch/amd64.h ../../binutils-gdb/gdb/arch/tdesc.h \ build-gnulib/import/stdint.h ../../binutils-gdb/gdb/common/x86-xstate.h \ build-gnulib/import/stdlib.h \