[Top][All Lists]

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

Re: Extension management, first sketch

From: Urs Liska
Subject: Re: Extension management, first sketch
Date: Mon, 20 Jan 2020 13:31:05 +0100
User-agent: Evolution 3.34.1-2+b1

Am Montag, den 20.01.2020, 10:27 +0100 schrieb Urs Liska:
> * A core extension library shipping with LilyPond will be initiated. 
>   Extensions that are considered core functionality (prime
> candidates:
>   edition-engraver, stylesheets) will eventually be moved here from
>   openLilyLib, additionally special functionality (e.g.,
> may over time be moved there to expose the difference
>   between core functionality and use-case specific modules more 
>   clearly. These tools will then be called through `\loadModule`
>   instead of `\include`, which will be easy to handle with
>   convert-ly rules. Probably it would be a good idea to eventually 
>   expose *all* non-standard notation through explicit packages
>   and have that nicely describe in the LM. This too will not be
>   called openLilyLib.

Thinking about it I would go one step further:

Currently we have a /ly folder in the installation which contains core
files like on the one hand, and on the other
hand optional files that users can \include for specific functionality,
such as the ones I have given as examples above.

I think now that *all* the files that are not included unconditionally
but only upon user request should be treated as packages. This will
make the code structure clearer, since there is a clear distinction
between the files LilyPond needs/uses for its startup (then *all* files
in /ly) and optional files at the user's disposition.


reply via email to

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