Merge branch 'tie-grace-fix' into staging

[lilypond.git] / Documentation / contributor / build-notes.itexi

diff --git a/Documentation/contributor/build-notes.itexi b/Documentation/contributor/build-notes.itexi
index bf779982290e370c48f89f3c5ecb92731b12ef02..b8dff79c1fae6f26dc8fff54e3da40e19946efe0 100644 (file)
--- a/Documentation/contributor/build-notes.itexi
+++ b/Documentation/contributor/build-notes.itexi
@@ -117,9 +117,11 @@ include $(configure-srcdir)/GNUmakefile.in
 
 The variable @code{depth} is used throughout the make system to
 track how far down the directory structure the make is.  The first
-include sets lots of variables but doesn't "do" anything.  The
-second runs the file @file{GNUmakefile.in} from the top level
-source directory.
+include sets lots of variables but doesn't "do" anything.  Default
+values for these variables are automatically detected at the
+./configure step, which creates the file @file{config.make}.
+The second include runs the file @file{GNUmakefile.in} from
+the top level source directory.
 
 This sets another load of variables, and then includes (i.e.
 immediately runs) @file{stepmake.make} from the @file{make}
@@ -196,9 +198,15 @@ which expands to the following files:
 
 One little feature to notice here - these are all absolute file
 locations - the line prior to this used relative locations.  And
-none of these files exist, either.  (Further note - I'm assuming
-all these lines of make I'm following are autogenerated, but
-that'll be something else to discover.)
+none of these files exist, either.
+
+(Further note - I'm assuming all these lines of make I'm following are
+autogenerated, but that'll be something else to discover.)
+
+JM: @emph{``No, these lines are not useful in LilyPond (this is why
+you think they are autogenerated), but they are part of StepMake,
+which was meant to be a package to be installed as a build system over
+autoconf/make in software project source trees.''}
 
 Next in @file{stepmake.make}:
 
@@ -286,11 +294,11 @@ are:
 
 @example
 $(outdir)/%.ly: %.lym4
-        $(M4) $< | sed "s/\`/,/g" > $@
+        $(M4) $< | sed "s/\`/,/g" > $@@
 
 $(outdir)/%: %.in
-        rm -f $@
-        cat $< | sed $(sed-atfiles) | sed $(sed-atvariables) > $@
+        rm -f $@@
+        cat $< | sed $(sed-atfiles) | sed $(sed-atvariables) > $@@
 @end example
 
 I believe the first rule is for *.ly files, and has a prerequisite
@@ -442,10 +450,10 @@ From git grep:
 stepmake/stepmake/generic-vars.make has this:
 
 @smallexample
-LOOP=+$(foreach i, $(SUBDIRS), $(MAKE) PACKAGE=$(PACKAGE) package=$(package) -C $(i) $@ &&) true
+LOOP=+$(foreach i, $(SUBDIRS), $(MAKE) PACKAGE=$(PACKAGE) package=$(package) -C $(i) $@@ &&) true
 @end smallexample
 
-$@ is the name of the target - WWW-1 in this case.
+$@@ is the name of the target - WWW-1 in this case.
 
 In GNUmakefile.in we find:
 
@@ -554,13 +562,16 @@ they're up to date.
 
 (From the make manual:
 
-To this end, after reading in all makefiles, make will consider each as a goal target and
-attempt to update it. If a makefile has a rule which says how to update it (found either
-in that very makefile or in another one) or if an implicit rule applies to it (see Chapter 10
-[Using Implicit Rules], page 103), it will be updated if necessary. After all makefiles have
-been checked, if any have actually been changed, make starts with a clean slate and reads
-all the makefiles over again. (It will also attempt to update each of them over again, but
-normally this will not change them again, since they are already up to date.)
+To this end, after reading in all makefiles, make will consider each
+as a goal target and attempt to update it. If a makefile has a rule
+which says how to update it (found either in that very makefile or in
+another one) or if an implicit rule applies to it (see Chapter 10
+[Using Implicit Rules], page 103), it will be updated if
+necessary. After all makefiles have been checked, if any have actually
+been changed, make starts with a clean slate and reads all the
+makefiles over again. (It will also attempt to update each of them
+over again, but normally this will not change them again, since they
+are already up to date.)
 
 So my assumption seems correct)
 
@@ -957,6 +968,7 @@ described to some extent at
 
 The file @file{lily-bib.bst} also has fairly extensive commenting.
 
+
 @node Website build
 @section Website build