Re: master e54b94c28cd: Use @xref more consistently; "See @ref" -> "@xref"

[Pip Cet]

"Michael Albinus" <michael.albinus@gmx.de> writes:

> Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
> writes:
>> I think if we add a new make target with the idea that you run it prior
>> to a push, we can then decide what precisely would be good for it to do
>> without having to rescind or amend our previously-issued advice.
>>
>> My suggestion is "make push", which would not run "git push" but should
>> probably include instructions to do that, if and only if the checks
>> succeeded.  ("prepush" might be the more obvious name, no reason not to
>> have both).
>>
>> For example, "make (pre)push" should probably fail if compiling a test
>> causes a warning; this is currently true due to bug#75633.
>
> I doubt it will help. We have already zillions of make targets; and
> there are targets which would fit your needs. If people don't find the
> proper target, we need to increase our doc. Not to include another
> target nobody will find or remember as well.

You've convinced me.  Let's go with "make check" for now, which has the
distinct advantage of being a standard GNU project target, so people
will remember it.

I'll be much more careful about suggesting new make targets.

> See also my proposal for the 'make -C test <filename>-tests' call prior
> to commit.

Thank you for making that more prominent in the documentation.  Clearly
this is a situation where we should make the most of the tools we have
before considering the with-drawn proposal of "make push" or anything
like that.

>> If we automate this and keep the auto-generated metadata out of the .el
>> files, what are the objections?
>
> It's not only *.el changes, but also *.c changes, for example. And other
> niggles we will run into.

I meant test/*/*.el, not the source files.  My impression was that the
proposal was to re-assign :expensive tags, modifying many test files; my
counterproposal was to store such secondary information outside of
test/*/*.el, where it won't cause merge conflicts or visible code
churn. But, again, upon reflection, I don't see the urgent need for such
secondary information anymore.

>> If it then turns out we don't need the manual :expensive tag at all
>> anymore, we can drop it.
>
> Bah! People still run 'make check' for good reasons, which is different
> from 'make check-expensive', called on emba for example.

Upon reflection, I agree.  My current understanding is "make
check-expensive" includes tests with the :expensive tag and "make check"
doesn't.  Let's keep it that way.

Thank you for your response.  Unless I seriously misread something,
you've convinced me and I withdraw all of my proposals in this thread.

Pip