GNU bug report logs - #31744
26.1; Improvements to make tags and make -C test

Previous Next

Package: emacs;

Reported by: Noam Postavsky <npostavs <at> gmail.com>

Date: Thu, 7 Jun 2018 01:51:02 UTC

Severity: wishlist

Tags: fixed, patch

Found in version 26.1

Fixed in version 26.2

Done: Noam Postavsky <npostavs <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #20 received at 31744 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31744 <at> debbugs.gnu.org
Subject: Re: bug#31744: 26.1; Improvements to make tags and make -C test
Date: Sat, 09 Jun 2018 15:16:00 -0400
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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?

Yeah, there's no way for Emacs to know where the build directory is.
Maybe I'll add symlinks locally to work around this.

>> 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.

I hope not, that sounds inconvenient to me.

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

Okay, I dropped this change, and updated the FIXME comment to mention
this instead.


Going back to a question from earlier in the thread:

>> +ifeq ($(TEST_INTERACTIVE), yes)
>> +	HOME=/nonexistent $(emacs) \
>> +	  -l ert ${ert_opts} \
>> +	  $(patsubst %,-l %,$(if $(findstring $(TEST_LOAD_EL),yes),$ELFILES,$(ELFILES:.el=)))  \
>> +	  $(TEST_RUN_ERT)
>> +else
>>  	-@${MAKE} -k  ${LOGFILES}
>> -	@$(emacs) -l ert -f ert-summarize-tests-batch-and-exit ${LOGFILES}
>> +	@$(emacs) --batch -l ert -f ert-summarize-tests-batch-and-exit ${LOGFILES}
>> +endif

> Not sure I understand the HOME trick: why not use -Q?

$(emacs) already includes -Q (or rather, the equivalent long options
--no-init-file --no-site-file --no-site-lisp).  The HOME trick was added
in [d17aa3e535] and [412c38aa28].  I can't find a specific discussion,
but http://lists.gnu.org/archive/html/emacs-devel/2017-05/msg00641.html
seems related.  I've added a comment to explain this better.

[412c38aa28]: 2017-05-30 08:39:39 -0700
  Stop make check interacting with HOME
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=412c38aa28dd7e8363b481a09d1df62c40f9a5b7
[d17aa3e535]: 2017-05-30 12:50:54 -0400
  Reduce scope of recent test/Makefile HOME change
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=d17aa3e535bba5e93ff188d5460c91001074255e

[v2-0001-Make-tags-targets-respect-with-silent-rules-Bug-3.patch (text/plain, attachment)]
[v2-0002-test-Makefile.in-Add-TEST_INTERACTIVE-option-Bug-.patch (text/plain, attachment)]
[v2-0003-Reduce-quoting-for-SELECTOR-in-make-C-test-Bug-31.patch (text/plain, attachment)]

This bug report was last modified 7 years and 38 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.