Jan Nieuwenhuizen wrote:
Brynne and Russ Jorgensen writes:
I'm not sure I understand, it seems that the test is for operating
system flavour, not for unicode functionality
Yes, that is right.
So, in that case, we'd better include something like
http://nsis.sourceforge.net/archive/viewpage.php?pageid=261
I thought that you said the unicode version of lilypad would work
Actually, you need to link the unicode version of lilypad against a
special library
Ok, I'm not going to be doing that, but I do take patches against CVS
module lilypond/installer/windows/lilypad.
Jan.
Jan,
I figured out a way to have a single executable contain both the unicode
and ascii versions of lilypad and it chooses at run time which one is
appropriate. Thought you might like it better than having two
executables and trying to make sure the right one gets installed.
Conceptually, I compile the source once for -DUNICODE and once for
-UUNICODE, link it all together, and WinMain() chooses which to use.
Sounds simpler than it really was - I ended up putting all of lilypad
into a C++ class so that I could solve the name clash problem by using a
different class name when compiling -DUNICODE and -UUNICODE. But, it
does work, and I think it turned out to be relatively elegant. If
you're interested in using this, let me know how to get the source to
you - since I changed c-files to cpp-files, I just tarballed the whole
thing which is too big to attach.
I also fixed the problem with parsing the command line so now
right-click "Edit source..." on a .ly file works.
-Russ
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
