On 11 Feb 2010, at 05:32, Carl Sorensen wrote:
I have been hunting, so far in vain, for the code implementing
\include,
in the hope that I can tweak that code to get the right behavior.
It appears to me that \include is implemented in two places:
1) lily/lexer.ll, lines 304-336
2) lily/lily-lexer.cc, lines 255-271
Now, please understand that I'm not at all an expert on the parser/
lexer of
LilyPond. But I think that lexer.ll calls new_input, and lily-
lexer.cc
defines new-input.
The .ll (or .l) file is what is passed to the lexer, and you probably
use Flex. It compiles the code to a .cc (or .c) file, which is then
passed to the compiler which produces .o object code, a format that
typically has embedded machine code, which is actually what is executed.
lily-lexer.ll is where the file identifier is extracted (lexed?),
and would
be an ideal place to see if the include has already been processed,
if the
necessary variable structure is available.
So this is the file that one would change. Then 'make' will sense that
this file hjas been changed, invoking flex, producing a new .cc file.
From what I can see on git.savannah, the \include definition in lily/
lily-lexer.ll just inserts the file in the stream using a method that
Flex provides.
By contrast, if one would want to have an import command that checks
that a module isn't loaded twice, one should have table for the module
names. Then an opened module is read all through, the definitions
entered into Guile, and then the module is closed.
This may not be so difficult to implement if there is some top level
command where lilypond starts reading the first file. Then the new \
\import just calls that command.
Hans
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
