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 7B3166DE019C for ; Thu, 24 Aug 2017 02:55:27 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.024 X-Spam-Level: X-Spam-Status: No, score=0.024 tagged_above=-999 required=5 tests=[AWL=0.044, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 b5q41CVKbMKT for ; Thu, 24 Aug 2017 02:55:26 -0700 (PDT) Received: from mail-qk0-f195.google.com (mail-qk0-f195.google.com [209.85.220.195]) by arlo.cworth.org (Postfix) with ESMTPS id EEA406DE0164 for ; Thu, 24 Aug 2017 02:55:25 -0700 (PDT) Received: by mail-qk0-f195.google.com with SMTP id l68so1770946qke.2 for ; Thu, 24 Aug 2017 02:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nikula-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oK0DH05V4B/+smSjPeoq0HPt+8qlFLCni84RqTEduvE=; b=rwaxw4Fd8iPMSdUAkhMxJbCuIS9BhHvZ6XtgnmSuGbCO/MmrdEnuD6oI9BtnYgr2GL wKvQHNStLYNKjkIqbgI207x8SBsDKYmAU92YeiTLuIg6uXWzXLuyl+WIkiyDhOTyvnCf RB7FMATgIXZlIukuvpv0+5EDY2/PuEOpa4W+Bss+nNhsWcK5C8aiidT9yCfVveAlzon1 KI4msGud5lsgfoSfJHMVCE5FQvxH1aDQfbwbVBcPKfOxkJVIaVTNkbHafpvt14g4Cx2b +IedcU7BIG7P5G2VCNRiKqulvuLJRweFSh62xlfvVysqlQfJ/bel/daHoX6J+pJWZNt5 MTRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oK0DH05V4B/+smSjPeoq0HPt+8qlFLCni84RqTEduvE=; b=M9qrbzCzZU40LhZyjq7HPvG0jg4Kypkzi837lNNSM/aXD8I2QeJEpHac7cwgtlsXvN Bt7NOe+M9shrUOF6lszQfWX+8Zwlv0AHfzVvM0l5/VeNy3gAgYE+1sMuzKW8WompMjA4 e3pejA8Su/oidHwf+So05C7P2TIFTXbM7GWbma4urUVrWujX4JGP2yngvKTk+L9m7ayh qJxsp5ekKYy+pgLZLW4VeiF4lZa046a1JJiKp0OfNKW4V/0RzPlpy+WGzwrHhOH7a3gI WegxfuTc2gSAyQTab+ONZpZSQOyMQVHN8/Ph7q09gqJkq0bqeP+g+HiltRbhWHvnScMY dCjQ== X-Gm-Message-State: AHYfb5h1I0cZRvZEYX7xsjHdBMJlW9CHx6PAByzTCIlf3YlBY4LvtEKG 1ezLmlvX2ZXULG6Fcb9J2MKXTla3qagy X-Received: by 10.55.27.85 with SMTP id b82mr8382704qkb.309.1503568524864; Thu, 24 Aug 2017 02:55:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.49.36 with HTTP; Thu, 24 Aug 2017 02:55:24 -0700 (PDT) In-Reply-To: References: <1503521740-32330-1-git-send-email-yuri.volchkov@gmail.com> <87d17lqzr5.fsf@nikula.org> From: Jani Nikula Date: Thu, 24 Aug 2017 12:55:24 +0300 Message-ID: Subject: Re: [PATCH] build: generate cscope and etags source indexes To: Yuri Volchkov Cc: Tomi Ollila , Notmuch Mail Content-Type: text/plain; charset="UTF-8" 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 09:55:27 -0000 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. > 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! ;) BR, Jani.