From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74743 invoked by alias); 16 Jan 2020 18:28:39 -0000 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 Received: (qmail 74730 invoked by uid 89); 16 Jan 2020 18:28:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-15.4 required=5.0 tests=AWL,BAYES_00,ENV_AND_HDR_SPF_MATCH,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_JMF_BL,SPF_PASS,USER_IN_DEF_SPF_WL autolearn=no version=3.3.1 spammy=HX-Received:6042, H*RU:209.85.167.193, HX-Spam-Relays-External:209.85.167.193 X-HELO: mail-oi1-f193.google.com Received: from mail-oi1-f193.google.com (HELO mail-oi1-f193.google.com) (209.85.167.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Jan 2020 18:28:29 +0000 Received: by mail-oi1-f193.google.com with SMTP id p125so19724410oif.10 for ; Thu, 16 Jan 2020 10:28:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=XfcvLbsakjiSePvIBX2aKGQG+U1dfzV42VyXEJ4lp9c=; b=PaE1FfI2DMsMyqLMwZcZlVbz+H+IXsgPwV3LZA4TEYxW3/d0dARii3b03gpzmiDkiS 5sl1hJhmeFULoQVLl4hS5DyI86nYO5GrK1eZez4xhYTuyTMBh+9nrEChV3G/BVL2l1y9 rDzSPW0e6/XI6NZ7bf0m6Ze8Yj4M5ERt40JJMEZjNLsZFUBcCGLDkF3kH7LN6ZPZIzky BSLb7jWXWSEMWNdNQtAF784/f291lqFmY83ux7UlL0ANMf/qPlE5wuxHe/o57iPE57Oa 1Pzckn5RMcbnJAeERPIVsizGFJfd3iDN+30K7Y3AfM/EPyyudco6k1Jg4m1a3Y+JaJZK /zNg== MIME-Version: 1.0 References: <20200109005807.7314-1-tom@tromey.com> <8a8de6a9-37b8-cad3-c818-be903037fe48@redhat.com> <437c1b86-0aa8-57b9-53e2-f21567e2bb14@redhat.com> <87c733a2-2b25-a954-88a1-9bfb1a7eca12@redhat.com> <4fed38dc-aaa7-b76b-880f-bab0b1b5add2@redhat.com> <09d7b39d-982d-d68b-a3c7-651616778bd5@redhat.com> <585a0731-74a2-7712-bb4f-8c69fdcecaf5@redhat.com> <14ba3eb4-c469-c4af-e497-02b6636613a7@redhat.com> In-Reply-To: <14ba3eb4-c469-c4af-e497-02b6636613a7@redhat.com> From: "Christian Biesinger via gdb-patches" Reply-To: Christian Biesinger Date: Thu, 16 Jan 2020 19:21:00 -0000 Message-ID: Subject: Re: [PATCH v2 0/6] Move gdbsupport to top level To: Pedro Alves Cc: Tom Tromey , gdb-patches Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00462.txt.bz2 On Thu, Jan 16, 2020 at 1:23 PM Pedro Alves wrote: > > On 1/16/20 5:38 PM, Christian Biesinger wrote: > > On Thu, Jan 16, 2020 at 11:23 AM Pedro Alves wrote: > >>> For that patch, why not just use AM_CFLAGS/AM_CXXFLAGS? > >> > >> I was mainly following what GDB does, with: > >> > >> COMPILE.pre =3D $(CXX) -x c++ $(CXX_DIALECT) > >> > >> I guess I was the one who did that, so that's not going to be > >> a strong explanation. :-) > >> > >> It's just that I feel like the compiler mode is more about > >> picking a different compiler than about picking some flags > >> like warnings flags or compilation levels. I think that > >> in practice the only difference is that you see the > >> -std=3Dgnu++11 next to the compiler command: > >> > >> $ rm -f selftest.o && make V=3D1 selftest.o > >> /opt/gcc-4.8/bin/g++ -std=3Dgnu++11 -DHAVE_CONFIG_H -I. -I/home/pedro/= gdb/binutils-gdb/src/gdbsupport -I/home/pedro/gdb/binutils-gdb/src/gdbsupp= ort/config.h -I/home/pedro/gdb/binutils-gdb/src/gdbsupport/../include -I/ho= me/pedro/gdb/binutils-gdb/src/gdbsupport/../gdb -I../gnulib/import -I/home/= pedro/gdb/binutils-gdb/src/gdbsupport/../gnulib/import -I.. -I/home/pedro/g= db/binutils-gdb/src/gdbsupport/.. -I../bfd -I/home/pedro/gdb/binutils-gdb/= src/gdbsupport/../bfd -g3 -O0 -MT selftest.o -MD -MP -MF .deps/selftest.T= po -c -o selftest.o /home/pedro/gdb/binutils-gdb/src/gdbsupport/selftest.c > >> mv -f .deps/selftest.Tpo .deps/selftest.Po > >> > >> vs, with AM_CFLAGS: > >> > >> $ rm -f selftest.o && make V=3D1 selftest.o > >> /opt/gcc-4.8/bin/g++ -DHAVE_CONFIG_H -I. -I/home/pedro/gdb/binutils-gd= b/src/gdbsupport -I/home/pedro/gdb/binutils-gdb/src/gdbsupport/config.h -I= /home/pedro/gdb/binutils-gdb/src/gdbsupport/../include -I/home/pedro/gdb/bi= nutils-gdb/src/gdbsupport/../gdb -I../gnulib/import -I/home/pedro/gdb/binut= ils-gdb/src/gdbsupport/../gnulib/import -I.. -I/home/pedro/gdb/binutils-gdb= /src/gdbsupport/.. -I../bfd -I/home/pedro/gdb/binutils-gdb/src/gdbsupport/= ../bfd -std=3Dgnu++11 -g3 -O0 -MT selftest.o -MD -MP -MF .deps/selftest.Tp= o -c -o selftest.o /home/pedro/gdb/binutils-gdb/src/gdbsupport/selftest.c > >> mv -f .deps/selftest.Tpo .deps/selftest.Po > >> > >> AFAICT, overriding CXXFLAGS or CXX in the make invocation works > >> the same in either case. > > > > How so? override is documented to override commandline variables? > > https://www.gnu.org/software/make/manual/html_node/Override-Directive.h= tml#Override-Directive > > > > Because it is defined in terms of CXX, which gets filled with whatever > was specified on the command line, I believe: > > override CXX :=3D $(CXX) $(CXX_DIALECT) > > I guess I should write instead: > > override CXX +=3D $(CXX_DIALECT) Oh, yeah, good point. Either way is fine with me. > > But yes, that's what I was thinking of, and just in general that > > override seems a bit ugly. > > Other than aesthetic reasons, do you see an issue? I like seeing > the -std=3Dgnu++11 at the left side of the command invocation, > basically for quick diagnostics, but that's about my only reason > for preferring it. Yeah since the overriding still works, I'm fine with this. Christian