On Sat, 2022-05-07 at 22:14 -0500, John Wheeler wrote: > On 5/7/22 06:05, David Kastrup wrote: > > David Kastrup <d...@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
