From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 449556DE0164 for ; Thu, 24 Aug 2017 03:12:00 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=0.123, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nHZPXkCeK1a for ; Thu, 24 Aug 2017 03:11:59 -0700 (PDT) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by arlo.cworth.org (Postfix) with ESMTPS id CB81B6DE00E6 for ; Thu, 24 Aug 2017 03:11:58 -0700 (PDT) Received: by mail-wm0-f66.google.com with SMTP id v186so2233576wmf.4 for ; Thu, 24 Aug 2017 03:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=bLFVZt/Ypqa9pWuHQanNc1UYTyPOEqpT3GAAZ/is9AY=; b=QgVmgxSSrOg3aAbdgRcqqAE5FENME6xIN6djNmbbYJcuuXIvd/OuY3CzaqVOsfuZuY NjsCpjmYX5I3W35Q94ZIFpjUiWTNiViuQP1aRvKU5yeXR37IM8BqFRWC9zvfXte4LBzA zNkZZ05zis4ZTtBx5/ybmiQv2aQBr2WL5+zZwm8/wsouCtbRcmQN800sw5RpqiZVR6o5 xJtNMshIgslKsrsfx38B1goXClQItkO5mbXe+3218gjb9/w6lGgmLrIaQLsTR5a3MOrE AIjlzbhK+7/J5SZ8cdmvRn6ATXsTh/2+TtxrLz/k/TXgnhr2Li9G1C8J1UQHmkmSi7bf 8w6A== 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:in-reply-to:references:date :message-id:mime-version; bh=bLFVZt/Ypqa9pWuHQanNc1UYTyPOEqpT3GAAZ/is9AY=; b=jaPqpr0F2i+2G6nNDxqL9m6wgL448wp5kYAb9rX3wnru/NRguDkt4HQ9/iKVxqgj7l 9TK1Amn2A2NVy2ViIQvP331GpVELegmimRwjj0J5bi/bgEnXVytXUKeefjiAJqf4mbcD mrxOlJs7o3jA27rMl7Obx60eeKLY0Yo2n57uWi2MohSCUwXHG551p2HwEV2StNaZbTs7 gHm6V+7eLzgn6wI/HZUaLhPeK4rr9GkbvNoCCAqqW3pDXhMOOUy39zRgIUiGLtvFwuk+ pLvJrdHqt4aDxia6lXkLx67n4lNFlhksvpLtjveZbV2ZvBxzuszeBOIM1od7kcMmE+wm Wfpw== X-Gm-Message-State: AHYfb5idPER9mLaKAEa0pAv+FGDdcLdQ7xPGkZsnKostJ1X1Ak7Q1Kjw 70Z77QxS3vLiyY5C5wE= X-Received: by 10.28.105.153 with SMTP id z25mr3371408wmh.169.1503569516291; Thu, 24 Aug 2017 03:11:56 -0700 (PDT) Received: from localhost (mito.neclab.eu. [195.37.70.39]) by smtp.gmail.com with ESMTPSA id v9sm3339908wmg.41.2017.08.24.03.11.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 03:11:55 -0700 (PDT) From: Yuri Volchkov To: Jani Nikula , Notmuch Mail Cc: Tomi Ollila Subject: Re: [PATCH] build: generate cscope and etags source indexes In-Reply-To: References: <1503521740-32330-1-git-send-email-yuri.volchkov@gmail.com> <87d17lqzr5.fsf@nikula.org> Date: Thu, 24 Aug 2017 12:11:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 10:12:00 -0000 Jani Nikula writes: > On Thu, Aug 24, 2017 at 12:13 PM, Yuri Volchkov wrote: >>>> $ git ls-files | gtags -f - >> I was trying to adapt developing patterns from the linux kernel, to >> which I used to. This was my bias :) >> >> The good thing about this approach is that only those files will be >> indexed, which are actually build in the current configuration. For >> linux it is absolutely must, because there is a huge number of >> functions, implemented differently for different architecture or >> configuration option. So only relevant files are getting into the >> index. >> >> However, I agree, a relatively small project as notmuch, almost does not >> suffer from this problem. > > FWIW I use the above snippet also for kernel work. More often than not > I want to find all the references. I think this is even more so for > notmuch, where you're more likely to do project wide refactoring. > >>>> In theory you'll be able to look at $(SRCS) for indexing... but those >>>> are only the .c/.cc files. Are your tools clever enough to follow >>>> #include directives to index the headers as well? >> Oops. Honestly this thing have slipped from my mind. I'll fix this if we >> decided this feature is needed, and if the result will not look too ugly. > > Not that the kernel tags targets are a good example for anything, but > they do use a bunch of complicated shell scripting to find the sources > in the file system. They don't look at the sources defined by > Makefiles for the configuration options. Figuring out the header files > in Makefiles is more trouble than it's worth. Well, for my needs kernel tags doing pretty good job. Partially because I use helm-git-grep whenever I need project-wide refactoring. But I agree, that machinery for building index is way too complicated in the kernel. That's why I said "not too ugly". > >> Also I have never tried gnu global. I need to check it out too. And >> again, if decided this helper is needed, I'll add gnu global too. > > Really the simplest thing for gnu global is to just run 'gtags' in the > top level directory, and let it recursively handle all files it > understands. Having to run 'make gtags' is not much of a convenience! > ;) I feel convinced. Just forget about this patch. > > BR, > Jani.