Re: etags regex for Lilypond & LY_DEFINE* tags

[Jonas Hahnfeld]

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

Jonas

signature.asc
Description: This is a digitally signed message part