lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: etags regex for Lilypond & LY_DEFINE* tags


From: Jonas Hahnfeld
Subject: Re: etags regex for Lilypond & LY_DEFINE* tags
Date: Mon, 09 May 2022 22:46:27 +0200
User-agent: Evolution 3.44.1

On Sun, 2022-05-08 at 22:10 -0500, John Wheeler wrote:
> On 5/8/22 09:17, Jonas Hahnfeld wrote: 
> > 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?

Yes, this sounds reasonable.

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

Indeed, the second regex would add a tag for the Scheme function name
before Jean's change. Maybe it's worth considering reverting it?

Jonas

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]