> PS: There might be typos in my modifications, so please test them.
Uff, indeed there are typos. Attached an improved version.
Werner
==
#
# This is a Makefile for `GNU make'!
# It uses extensions not available in most
> Does this now resemble something I can make generic and put in the
> docs?
Not yet. See below for something which fits better the 80 chars line
length limit.
You've forgotten the driver files for the full score and the
movements; I've added it now. Note that it wouldn't be necessary to
menti
On Sun, May 17, 2009 at 09:35:29PM -0500, Jonathan Kulp wrote:
> Patrick,
>
> I reset my git repo, re-did the changes, and made a new patch. A
> bunch of the changes are stripped whitespaces. I think I got all
> the vim *.ily stuff in there this time, though. New patch attached.
Great, it appl
Patrick,
I reset my git repo, re-did the changes, and made a new patch. A bunch of
the changes are stripped whitespaces. I think I got all the vim *.ily stuff
in there this time, though. New patch attached.
Jon
On Sun, May 17, 2009 at 6:48 PM, Jonathan Kulp wrote:
> Patrick McCarty wrote:
>
Peter Chubb wrote:
Jonathan> What I can't figure out how to make it do is recompile a
Jonathan> score whose \include "notes.ily" file has changed, something
Jonathan> that is much more likely to happen than the main.ly file.
Jonathan> I've added .ily to the list of suffixes, and I added a line
Jo
Patrick McCarty wrote:
Hmm. That's weird. I don't see the changes you made to
vim/lilypond-ftdetect.vim reflected in the patch.
If you run `git status', does it say that you have nothing to commit?
If not, then something might have went astray in the process of
amending the commit.
Here's
> "Jonathan" == Jonathan Kulp writes:
Jonathan> What I can't figure out how to make it do is recompile a
Jonathan> score whose \include "notes.ily" file has changed, something
Jonathan> that is much more likely to happen than the main.ly file.
Jonathan> I've added .ily to the list of suffixe
Werner LEMBERG wrote:
The terminal output for individual jobs is lost, but it processes
much faster.
Redirect the logging output to log files.
[red face]The -djob-count flag automatically causes log files to be
created and saved in the working directory. Very smart...
Jon
--
Jonathan Kul
Werner LEMBERG wrote:
A limitation is that the directories in `VPATH' are not expanded and
must be given directly (this seems to be undocumented; I'll contact
the GNU make people):
This was my mistake. I forgot about the `shell' function. Here's a
revised version of the Makefile.
Thanks We
On Sun, May 17, 2009 at 05:04:18PM -0500, Jonathan Kulp wrote:
> On Sat, May 16, 2009 at 3:24 AM, Patrick McCarty wrote:
>
> > That's correct. At one point, I had filetype.vim in my ~/.vim
> > directory too, but since ftdetect/lilypond.vim does (basically) the
> > same thing, I've just been usin
On Sat, May 16, 2009 at 3:24 AM, Patrick McCarty wrote:
> That's correct. At one point, I had filetype.vim in my ~/.vim
> directory too, but since ftdetect/lilypond.vim does (basically) the
> same thing, I've just been using this file.
>
> > I've already made the change to lilypond-ftdetect.vim
> "Jonathan" == Jonathan Kulp writes:
Jonathan> Peter Chubb wrote:
>> There are alternatives. The main objection I have to the form of
>> makefile you propose is that dependencies are not tracked, so
>> editing one file will either not rebuild anything, or will rebuild
>> everything (dependi
>> A limitation is that the directories in `VPATH' are not expanded
>> and must be given directly (this seems to be undocumented; I'll
>> contact the GNU make people):
>
> This was my mistake. I forgot about the `shell' function. Here's a
> revised version of the Makefile.
And two other correct
Francisco Vila writes:
> 2009/5/17 David Kastrup :
>> \notelanguage "english" { ... }
>>
>> which switches the parser to english language while parsing the given
>> expression (and loads internally some .ily file once with the required
>> information if necessary, retaining it for further switche
> A limitation is that the directories in `VPATH' are not expanded and
> must be given directly (this seems to be undocumented; I'll contact
> the GNU make people):
This was my mistake. I forgot about the `shell' function. Here's a
revised version of the Makefile.
Werner
===
> The terminal output for individual jobs is lost, but it processes
> much faster.
Redirect the logging output to log files.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
> INPUTS= $(wildcard *.ly)
IMHO, exactly THIS statement should be replaced with an explicit list
of all input files so that you can disable or enable files at your
wish. Using the `\' character to suppress the end of line, you can
structure this very nicely:
INPUTS = \
foo-a.ly \
foo-
On Sun, May 17, 2009 at 05:28:46PM +0200, David Kastrup wrote:
> Graham Percival writes:
>
> > I really meant things like spanner-init.ly : fundamental lilypond
> > .ly files which must be loaded. But yes, it should also be done
> > to things like english.ly.
>
> I always considered \include fo
2009/5/17 David Kastrup :
> \notelanguage "english" { ... }
>
> which switches the parser to english language while parsing the given
> expression (and loads internally some .ily file once with the required
> information if necessary, retaining it for further switches).
Why not
{ \setNoteLangua
Werner LEMBERG wrote:
[...] I'm wondring about a portable way to determine the number of
cores/CPUs present to adjust job-count value.
On Linux:
CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
Nice! I'd never tried using both processors like that. The terminal
outp
Graham Percival writes:
> On Sat, May 16, 2009 at 06:12:28PM -0500, Jonathan Kulp wrote:
>> Graham Percival wrote:
>>> In the large "DOC: Makefile" thread that nobody new is going to
>>> read, there was a proposal to use .ily to indicate "setup"
>>> lilypond files.
>>>
>> by "setup" files do you
Peter Chubb wrote:
There are alternatives. The main objection I have to the form of
makefile you propose is that dependencies are not tracked, so editing
one file will either not rebuild anything, or will rebuild everything
(depending on the rules).
In general, it's best to name all the inputs
> [...] I'm wondring about a portable way to determine the number of
> cores/CPUs present to adjust job-count value.
On Linux:
CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
Werner
___
lilypond-devel mailing list
lilypo
Anthony W. Youngman a écrit :
I think you missed the "&" in my code :-)
If the "wait" isn't there, the mv will fail because there won't be any
*.pdf files for it to move. Werner's point about multiple invocations
of lilypond is very valid, but on a multi-processor machine my
technique will us
24 matches
Mail list logo
