Re: DOCS: revising LM "Score and Parts"

[Henning Plumeyer]

Am 27.05.2009, 04:41 Uhr, schrieb Jonathan Kulp <address@hidden>:

> Henning Plumeyer wrote:
> > Am 26.05.2009, 04:13 Uhr, schrieb Jonathan Kulp  
> > <address@hidden>:
> >
> > > I had to comment out one more thing before it would run properly,  
> > > though--the "-djob-count" option, something we put in on the Linux  
> > > version to take advantage of dual processors.  It choked on that  
> > > saying "unbound variable 'primitive-fork'".  This could be because I'm  
> > > running on a virtual machine, though.  Did it work properly for you  
> > > with the multiple jobs option?
> >  Hi Jon,
> > it worked properly for me. Maybe you got the long line cut like I saw
> > it on the gmane web interface. Below I put a version with three lines
> > for the lilypond command (as attachement also).
>
> Hmm.  It still doesn't work for me with the job-count option.  It must  
> be because I'm using virtual machines.

What do you get if you type  "set n" (Without the quotes)? It gives all
environment variables beginning with n or N. Is there
NUMBER_OF_PROCESSORS?

> >  BTW: I got no difference with the "-djob-count" or without it.
> >    With the option: 2:45.218
> >    without        : 2:45.000(!)
> > (On a 2.2GHz Athlon 64 X2 Dual Core Processor--is that a normal time?)
> > Seems as if the option should be omitted on Windows for simplicity.

The numbers 2:45.xxx are seconds of command duration (sorry, I didn't
write a unit after them). As you see, the "-djob-count" option has no
use at least for me.

> >  I also got a way to work around the path-with-blank(s) problem.
> > Instead of CURDIR I fill and use a variable "workdir" in VPATH.
> > (Change the name if you like, I'm not a native speaker.) The used
> > technique for getting the 8.3 version of CURDIR is explained near
> > the end of the help for the command for ("for /h" on the Windows
> > commandline).
>
> I like this.  It's probably essential for Windows versions earlier than  
> Vista that have the spaces in the dirnames.  Thanks for figuring this  
> out.  It works great.
Fine.

> > Instead of %%b %%a could be used, but as a German I don't like sa...
> >  I am looking for a way to distinguish from within the makefile
> > if make is running on Linux or Windows. Perhaps we could use the
> > environment variable "OS" which is OS=Windows_NT on my computer.
> >  make has "ifdef variable-name" and "ifeq (arg1, arg2)", so there
> > should be a chance. Then perhaps it could be possible to have the
> > same makefile for Linux (and OSX?) and Windows.
> >  Does Linux have a varialble OS? If not, we can check for
> > existence, if yes we check the value.
>
> When I run "env" I don't get a value for OS.  In my shell scripts that I  
> want to run on either Linux or Mac OSX, I check OS with this:
>
> OS=$(uname)
>
> Really, though, I think it's probably best to have two different  
> Makefiles to avoid complication.  These are intended to give noobs  
> direction in creating their own, and for me it's better to reduce the  
> complications.
I agree, as it is an example it should be as simple as possible.

> > Regarding the mid/midi thing:
> >  We could use -dmidi-extension to set the default file extension
> > for MIDI output file to midi, but that touches the question of
> > the proper extension for midi.
> > (http://news.gmane.org/find-root.php?message_id=%3c20090408193658.GA2963%40zonnet.nl%3e)  
> >   Could we let lilypond give us the answer itself?
> > On Windows:
> > MidiExtWithQuotes = $(shell for /f "delims=() tokens=2" %%a in \
> >             ('lilypond -dhelp 2^>nul^|find "midi-extension"') \
> >             do echo %%a)
> >  How can this be achived on Linux? You would have to build a
> > command that gives
> > midi
> > and nothing else.
>
> This is a pretty cool feature you've written but I'm inclined just to  
> live with .mid for the sake of simplicity.
Yes.

> At one point I had a target to create only midi, but now I'm letting the  
> midi files be created by the "movements" target.  None of the other  
> targets create midi files.  It would be easy to have a midi-only target  
>   with the -dno-print-pages option, I guess.  Do you think it would be  
> better to separate midi into its own target?
No, because I think midi is often used to check if everything is correct.
If you then hear a mistake you need the pdf to see what is written. For
this purpose, pdf and mid belong together.

I think you will modify the file as you want. Ask me if you want me to
do that.

Henning