unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Noam Postavsky <npostavs@gmail.com>
Cc: 31744@debbugs.gnu.org
Subject: bug#31744: 26.1; Improvements to make tags and make -C test
Date: Sat, 09 Jun 2018 09:20:53 +0300	[thread overview]
Message-ID: <83fu1wtr96.fsf@gnu.org> (raw)
In-Reply-To: <87po10226z.fsf@gmail.com> (message from Noam Postavsky on Fri, 08 Jun 2018 21:12:04 -0400)

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: 31744@debbugs.gnu.org
> Date: Fri, 08 Jun 2018 21:12:04 -0400
> 
> >>> * src/Makefile.in: Create TAGS files in ${srcdir}, not build dir.
> >>
> >> I'm not sure I agree with this.  Other projects I looked at produce
> >> TAGS in the build directory (but reference source files in srcdir, of
> >> course).  Why do you think TAGS should go to the source directory?
> 
> Oh, hmm.  The original reason, is that when looking at a source file in
> Emacs, and then hitting M-. I get a prompt to visit the TAGS table,
> which starts from the source directory.  Then I have to go looking for
> the TAGS file in the corresponding build directory.

I have grown a habit a long time ago to "M-x visit-tags-table" before
I issue the first "M-." command.

The default prompt is fine, because what else would you expect Emacs
to do in that case?  But no one said that default is correct in every
single use case.  E.g., a project could have one TAGS file in a
top-level directory, and you may be visiting a file in a subdirectory.

> especially since every build directory will have identical TAGS
> files anyway

That's what happens currently, but it isn't carved in stone.  We
could, for example, have TAGS reflect only the files that are compiled
in on the current platform; other projects (like GDB, for example) do
just that.  Then each build will have a different TAGS file.

> > They should not. Source should be able to be mounted read-only, and
> > all build products should be stored elsewhere.
> 
> Emacs puts .elc files in the source directory.

*.elc files are generated at bootstrap time; when you build a tarball,
they are already there.  By contrast, TAGS is built at build time and
doesn't come with the release tarball.

> I was under the impression that the general principal is that arch &
> config dependent files go in the build directory, and arch & config
> independent ones go in the source directory.

No, I think the principle is that the source tree holds everything
that comes with a release tarball.





  reply	other threads:[~2018-06-09  6:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07  1:49 bug#31744: 26.1; Improvements to make tags and make -C test Noam Postavsky
2018-06-08 15:38 ` Eli Zaretskii
2018-06-08 16:04   ` Robert Pluim
2018-06-09  1:12     ` Noam Postavsky
2018-06-09  6:20       ` Eli Zaretskii [this message]
2018-06-09 19:16         ` Noam Postavsky
2018-06-10 16:59           ` Eli Zaretskii
2018-06-12 11:49             ` Noam Postavsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83fu1wtr96.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=31744@debbugs.gnu.org \
    --cc=npostavs@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).