[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Modularity in lilypond
From: |
Graham Percival |
Subject: |
Re: Modularity in lilypond |
Date: |
Thu, 29 Jul 2010 14:35:52 -0700 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Thu, Jul 29, 2010 at 08:17:38PM +0200, Mike Solomon wrote:
> True that.
Please do not top-post.
> My three.5 concerns are:
> 1) said code cannot use non-public scheme functions (am I right in thinking
> that?).
I'm not certain about this.
> 2) changes to init.ly are not copied from one version of lilypond to the
> next, nor are one person's "modules". I do my compiling from the git
> repository, so I could likely rig something like that for my own machine,
> but I imagine this is even more problematic for someone downloading a
> GUB-made lilypond. I had this problem with my site-packages when I updated
> from Python 2.4 to 2.6, and it took me days to get back things as I had
> them.
It would not be hard to add functionality to let people put their
own "modules" in ~/.lilypond/ or whatever. In fact, Reinhold's
recent patch for --user-include already supplies this
functionality, although we might want to provide syntactic sugar
by adding a --module-dir option. The "relative include paths"
feature, which may or may not be in the docs yet, also helps with
this task.
> 3) There should be some sorta standard practice (ie template) for how
> modules are written (I believe that's what David was referring to).
I don't think that this is what David was talking about, but of
course such templates would be useful.
And, by the way, I've been trying to recruit somebody to organize
/ly/ for at least the past three years.
> 3.5) I stand by my assertion that certain features of lilypond should be
> turned into modules if lilypond is to grow to be as encompassing as
> something like j-edit or emacs.
As a general rule? Sure.
Look, you're mixing up a few issues.
1. what are the technical limits of the functionality which can be
added as the result of an \include "foo.ly" statement?
(loading libraries, defining non-public scheme functions,
redefining syntax, changing font heads...)
AFAIK, we don't have a clearly known+documented set of limits.
This would be useful to work on.
2. how should the dirs be organized?
This is an idea from 3 or 4 years ago. Nothing is going to happen
until 2.14 is out. And there's no point trying to seriously
discuss this until #1 is settled.
3. how can we make this easy for users?
No point discussing this until #1 is settled.
If people think that I'm not being very encouraging, I'd like to
remind them that we currently have 15 patches waiting for review
or revision, including 2 for Critical issues, and that we (as a
community of developers) are being terribly unsupportive in not
spending more effort helping those patches get finished.
Cheers,
- Graham