Re: etags regex for Lilypond & LY_DEFINE* tags

[John Wheeler]

On 5/8/22 09:17, Jonas Hahnfeld wrote:
> On Sat, 2022-05-07 at 22:14 -0500, John Wheeler wrote:
> >   On 5/7/22 06:05, David Kastrup wrote:
> > > David Kastrup<dak@gnu.org>  writes:
> > > > Jonas Hahnfeld via Discussions on LilyPond development
> > > > <lilypond-devel@gnu.org>  writes:
> > > > > I've traditionally been opposed to adding more such scripts to
> > > > > the LilyPond tree, mostly because I spent way too much time
> > > > > trying to understand what existing and entirely undocumented
> > > > > ones were doing and how they were broken in a zillion ways. My
> > > > > take is that the LilyPond repository must only contain what is
> > > > > needed to build and maintain LilyPond. IMHO a convenience
> > > > > script (as far as I understand it) does not fall into this
> > > > > category, and I would vote *not* to include it.
> > > > I cannot follow the characterisation as a "convenience script"
> > > > here: making Emacs properly cross-reference functions is IDE
> > > > support. We similarly have IDE support in `.dir-locals.el`.
> > > > There is no real point in doing this in a separate repository
> > > > since the only use is in connection with working in the LilyPond
> > > > source tree.
> > > By the way: the convention for making this work bypasses the means
> > > of implementation (convenience script, pattern file for etags,
> > > whatever) and provides this functionality as
> > >
> > >      make tags
> > >
> > > The resulting tags file is usable for both Emacs and vi (and other
> > > tools using the same mechanism).
> > Thank you for pointing out that this functionality should be handled
> > by 'make TAGS'. For me, 'make TAGS' returns empty tags files,
> > presumably because I am building in a directory outside of the source
> > tree.  I will admit that when I discovered that behavior, I opted to
> > write a script rather than to attempt to understand/modify the make
> > process.
> Let me give a (very biased) summary of this: There's apparently a
> related (and undocumented) 'make TAGS' that is broken for out-of-tree
> builds. Instead of fixing this, the proposal was to add at least two
> new scripts with a parallel infrastructure. If we did this, then a few
> years from now somebody would wonder why there are two solutions and
> need to dig out the whole story again. This should really ring
> everybody's alarm bells of a path that is not at all maintainable!
I absolutely agree with making changes in the correct manner. I spent too
much of my career managing configuration change processes not to know
the pain doing it wrong will cause.  In many respects I share your bias.

If I understand you correctly, the right way to address this is to fix the
'make TAGS' feature and to document it.

Would you agree?

> > I will investigate whether I can add my desired functionality to
> > 'make TAGS'.
> Please note that 'lily/GNUmakefile' already has '--regex' for dealing
> with LY_DEFINE. I don't know whether that still works after Jean's
> recent changes, I think it should. At least on the C++ side; I don't
> immediately see links between C++ and Scheme, and I'm not sure this is
> desired.
Yes,  part of the existing --regex for LY_DEFINE was broken by Jean's 
MR!1329.

Thank you,
John Wheeler