On 22 January 2016 at 11:15, Urs Liska <u...@openlilylib.org> wrote: > > What I'm thinking about is the following: > > I have the file openlilylib.ily, which is the main entry point to > openLilyLib. > I'm currently changing the way how openLilyLib is organized. Previously > you loaded openLilyLib, and then you had the command \useLibrary to load > specific libraries from within openLilyLib. > In the future the libraries will be in separate repositories each > (disentangling code, distribution, collaboration and whatever). > For example you'll have the directories > openlilylib/scholarly > openlilylib/oll-core > > You'll "load" the ScholarLY library by including its main file (e.g.) > openlilylib/scholarly/main.ily, and this will in turn include > openlilylib/oll-core/main.ily. > > So as a user you won't write > \include "openlilylib" > \useLibrary Scholarly > anymore but > \include "scholarly/main.ily" > (or something similar) > > Now the question comes: > openLilyLib registers a list of loaded libraries and its options. What I'm > thinking about is if a function inside openlilylib/oll-core/main.ily can > determine from which file it has been included and then add this to the > list of loaded libraries. > > If that's not possible that wouldn't be much of an issue. ScholarLY would > then simply have to include oll-core and *then* issue a command to register > itself with oll. But I just wanted to explore the possibility. > > Urs > > Yes, ScholarLY registering itself via some function in oll-core is probably a much better solution anyway. If you think in terms of "Scholarly USES oll-core" it doesn't make sense for oll-core to do anything other than provide functionality to the other.
You could still wrap this behaviour up in a short top-level file that looks something like: ``` \include "oll-core.ily" \include "scholarly-impl.ily" oll-register ( scholarly ) ``` Chris
_______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user