From patchwork Wed Aug 20 22:29:26 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 381835 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 95D701400AB for ; Thu, 21 Aug 2014 08:29:39 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=nHWCduXb378nVbDu9uy/EoDw5Aca4UBhPsVeegzUjc84qx gj628R5p0UidUMfdWvL25b0v4nZL6z+vHx3vbO3yw64gxmkS5z148Poa8Ozfx73H 2GKYg9rsgLq8UQCTN94ZFncEpAuReDl6aSwwHZ+ThcLXm8f4mIST36Gtpk0vQ= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=WqNmmGfjx6ajjD5N7YjcjNt9WCQ=; b=SjvXtI4TvaIQ2OI95BlU TDdrvJVQ7ln8NVXR+0bLnsFiSgMhkMFRIr3axTaMvahFzWMlsXkkWpXEnMCKauTR h9c4VioyoCtVZmBAlvz/zL/Lbz8m9Zy+NigpWep2I0Ifea3oMGUoSH8SUBHbdRKW XlGH1XG4Sx80UHDGsI+tbjE= Received: (qmail 16539 invoked by alias); 20 Aug 2014 22:29:31 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 16528 invoked by uid 89); 20 Aug 2014 22:29:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 20 Aug 2014 22:29:29 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7KMTSWo026648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 20 Aug 2014 18:29:28 -0400 Received: from reynosa.quesejoda.com (vpn-55-110.rdu2.redhat.com [10.10.55.110]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7KMTRJm025453 for ; Wed, 20 Aug 2014 18:29:27 -0400 Message-ID: <53F52146.5010204@redhat.com> Date: Wed, 20 Aug 2014 15:29:26 -0700 From: Aldy Hernandez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: gcc-patches Subject: TAGs for variables created through common.opt What are the rules for etags, is it fair game to generate them for variables defined in the build directory (as opposed to the source directory)? For instance, my editor can't find flag_generate_lto because the TAGS rule in Makefile.in runs etags for source file *.h files (not those in the build directory). Is it fair game to generate tags for "options.h" in the build directory, as this patch does? The attached patch would point flag_generate_lto to the extern definition below. Not ideal, but close enough: #ifdef GENERATOR_FILE extern int flag_generate_lto; #else int x_flag_generate_lto; #define flag_generate_lto global_options.x_flag_generate_lto I suppose if we wanted to be pedantic, we should point it to the source in common.opt, but that would require: a) hacking etags to support our .opt language. b) hack one of the opt*.awk files to generate ad-hoc TAG entries directly. c) Or perhaps even, add semicolons to the end of variable entries in the .opt files. That way, we could more or less trick etags into thinking it's C. Though things like HOST_WIDE_INT variables would not work. Yes, I'm that lazy. Why should I have to look around for something that can clearly be automated? Aldy diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 1b3820b..549e7a3 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -3792,6 +3792,7 @@ paranoia: paranoia.o real.o $(LIBIBERTY) # Update the tags table. TAGS: lang.tags + BUILD_DIR=`pwd`; \ (cd $(srcdir); \ incs= ; \ list='$(SUBDIRS)'; for dir in $$list; do \ @@ -3799,7 +3800,8 @@ TAGS: lang.tags incs="$$incs --include $$dir/TAGS.sub"; \ fi; \ done; \ - etags -o TAGS.sub c-family/*.h c-family/*.c *.h *.c *.cc; \ + etags -o TAGS.sub c-family/*.h c-family/*.c *.h *.c *.cc \ + $$BUILD_DIR/options.h; \ etags --include TAGS.sub $$incs) # -----------------------------------------------------