1 @c -*- coding: utf-8; mode: texinfo; -*-
4 @node Build system notes
5 @chapter Build system notes
7 @warning{This chapter is in high flux, and is being run in a
8 @qq{wiki-like} fashion. Do not trust anything you read in this
12 * Build system overview::
13 * Tips for working on the build system::
14 * General build system notes::
17 * Building an Ubuntu distro::
21 @node Build system overview
22 @section Build system overview
24 Build system is currently GNU make, with an extra "stepmake" layer
25 on top. Look at files in @file{make/} and @file{stepmake/} and
26 all @file{GNUmakefile}s.
28 There is wide-spread dissatisfaction with this system, and we are
29 considering changing. This would be a huge undertaking (estimated
30 200+ hours). This change will probably involve not using GNU make
31 any more -- but a discussion about the precise build system will
32 have to wait. Before we reach that point, we need to figure out
33 (at least approximately) what the current build system does.
35 Fundamentally, a build system does two things:
39 Constructs command-line commands, for example:
43 --tons --of --options \
46 --more --imperial --and --metric --tons --of --options \
51 If there was a previous build, it decides which parts of the
52 system need to be rebuilt.
56 When I try to do anything in the build system, it helps to remind
57 myself of this. The "end result" is just a series of command-line
58 commands. All the black magick is just an attempt to construct
61 @node Tips for working on the build system
62 @section Tips for working on the build system
74 to the build system files in various places. This will let you
75 track where the program is, in various points of the build.
78 First task: understand how @code{make website} works,
79 @emph{without} the translations. Looking at the english-only
80 website is the best introduction to the build system... it only
81 covers about 5% of the whole thing, but even that will likely take
87 @node General build system notes
88 @section General build system notes
91 * How stepmake works::
94 @node How stepmake works
95 @subsection How stepmake works
97 Typing make website runs the file @file{GNUmakefile} from the
98 build directory. This only contains 3 lines:
102 include config$(if $(conf),-$(conf),).make
103 include $(configure-srcdir)/GNUmakefile.in
106 The variable @code{depth} is used throughout the make system to
107 track how far down the directory structure the make is. The first
108 include sets lots of variables but doesn't "do" anything. The
109 second runs the file @file{GNUmakefile.in} from the top level
112 This sets another load of variables, and then includes (i.e.
113 immediately runs) @file{stepmake.make} from the @file{make}
114 subdirectory. This sets a load of other variables, does some
115 testing to see if SCONS (another build tool?) is being used, and
116 then runs @file{make/config.make} - which doesn't seem to exist...
118 GP: scons is indeed a different build tool; I think that Jan
119 experimented with it 5 years ago or something. It seems like we
120 still have bits and pieces of it floating around.
122 Next, it runs @file{make/toplevel-version.make}, which sets the
123 version variables for major, minor, patch, stable, development and
124 mypatchlevel (which seems to be used for patch numbers for
125 non-stable versions only?).
127 Next - @file{make/local.make}, which doesn't exist.
129 Then a few more variable and the interesting comment:
132 # Don't try to outsmart us, you puny computer!
133 # Well, UGH. This only removes builtin rules from
136 and then tests to see whether BUILTINS_REMOVED is defined. It
137 appears to be when I run make, and so
138 @file{stepmake/stepmake/no-builtin-rules.make} is run. The
139 comment at the head of this file says:
142 # UGH. GNU make comes with implicit rules.
143 # We don't want any of them, and can't force users to run
147 I've not studied that file at length, but assume it removes all
148 make's build-in rules (e.g. @file{*.c} files are run through the
149 GNU C compiler) - there's a lot of them in here, and a lot of
150 comments, and I'd guess most of it isn't needed.
152 We return to @file{stepmake.make}, where we hit the make rule all:
153 The first line of this is:
156 -include $(addprefix $(depth)/make/,$(addsuffix -inclusions.make, $(LOCALSTEPMAKE_TEMPLATES)))
159 which, when the variables are substituted, gives:
162 ./make/generic-inclusions.make
163 ./make/lilypond-inclusions.make.
166 (Note - according to the make documentation, -include is only
167 different from include in that it doesn't produce any kind of
168 error message when the included file doesn't exist).
170 And the first file doesn't exist. Nor the second. Next:
173 -include $(addprefix $(stepdir)/,$(addsuffix -inclusions.make, $(STEPMAKE_TEMPLATES)))
176 which expands to the following files:
179 /home/phil/lilypond-git/stepmake/stepmake/generic-inclusions.make
180 /home/phil/lilypond-git/stepmake/stepmake/toplevel-inclusions.make
181 /home/phil/lilypond-git/stepmake/stepmake/po-inclusions.make
182 /home/phil/lilypond-git/stepmake/stepmake/install-inclusions.make.
185 One little feature to notice here - these are all absolute file
186 locations - the line prior to this used relative locations. And
187 none of these files exist, either. (Further note - I'm assuming
188 all these lines of make I'm following are autogenerated, but
189 that'll be something else to discover.)
191 Next in @file{stepmake.make}:
194 include $(addprefix $(stepdir)/,$(addsuffix -vars.make, $(STEPMAKE_TEMPLATES)))
200 /home/phil/lilypond-git/stepmake/stepmake/generic-vars.make
201 /home/phil/lilypond-git/stepmake/stepmake/toplevel-vars.make
202 /home/phil/lilypond-git/stepmake/stepmake/po-vars.make
203 /home/phil/lilypond-git/stepmake/stepmake/install-vars.make.
206 Woo. They all exist (they should as there's no - in front of the
207 include). @file{generic-vars.make} sets loads of variables
208 (funnily enough). @file{toplevel-vars.make} is very short - one
209 line commented as @code{# override Generic_vars.make:} and 2 as
214 include $(stepdir)/documentation-vars.make
217 I assume the urg comment refers to the fact that this should
218 really just create more variables, but it actually sends us off to
219 @file{/home/phil/lilypond-git/stepmake/stepmake/documentation-vars.make}.
221 That file is a 3 line variable setting one.
223 @file{po-vars.make} has the one-line comment @code{# empty}, as
224 does @file{install-vars.make}.
226 So now we're back to @file{stepmake.make}.
231 # ugh. need to do this because of PATH :=$(top-src-dir)/..:$(PATH)
232 include $(addprefix $(depth)/make/,$(addsuffix -vars.make, $(LOCALSTEPMAKE_TEMPLATES)))
235 and the include expands to:
238 include ./make/generic-vars.make ./make/lilypond-vars.make.
241 These again set variables, and in some cases export them to allow
242 child @code{make} processes to use them.
244 The final 4 lines of @file{stepmake.make} are:
247 include $(addprefix $(depth)/make/,$(addsuffix -rules.make, $(LOCALSTEPMAKE_TEMPLATES)))
248 include $(addprefix $(stepdir)/,$(addsuffix -rules.make, $(STEPMAKE_TEMPLATES)))
249 include $(addprefix $(depth)/make/,$(addsuffix -targets.make, $(LOCALSTEPMAKE_TEMPLATES)))
250 include $(addprefix $(stepdir)/,$(addsuffix -targets.make, $(STEPMAKE_TEMPLATES)))
253 which expand as follows:
256 include ./make/generic-rules.make ./make/lilypond-rules.make
258 /home/phil/lilypond-git/stepmake/stepmake/generic-rules.make
259 /home/phil/lilypond-git/stepmake/stepmake/toplevel-rules.make
260 /home/phil/lilypond-git/stepmake/stepmake/po-rules.make
261 /home/phil/lilypond-git/stepmake/stepmake/install-rules.make
262 include ./make/generic-targets.make ./make/lilypond-targets.make
264 /home/phil/lilypond-git/stepmake/stepmake/generic-targets.make
265 /home/phil/lilypond-git/stepmake/stepmake/toplevel-targets.make
266 /home/phil/lilypond-git/stepmake/stepmake/po-targets.make
267 /home/phil/lilypond-git/stepmake/stepmake/install-targets.make
270 @file{lilypond-rules.make} is @code{#empty}
271 @file{generic-rules.make} does seem to have 2 rules in it. They
275 $(outdir)/%.ly: %.lym4
276 $(M4) $< | sed "s/\`/,/g" > $@
280 cat $< | sed $(sed-atfiles) | sed $(sed-atvariables) > $@
283 I believe the first rule is for *.ly files, and has a prerequisite
284 that *.lym4 files must be built first. The recipe is @code{m4 |
285 sed "s/\`/,/g" >}. Perhaps someone with more Unix/make knowledge
286 can comment on exactly what the rules mean/do.
288 @file{toplevel-rules.make} is @code{#empty}
289 @file{po-rules.make} is @code{#empty}
290 @file{install-rules.make} is @code{#empty}
291 @file{generic-targets.make} contains 2 lines of comments.
292 @file{lilypond-targets.make} contains only:
295 ## TODO: fail dist or web if no \version present.
297 grep -L version $(LY_FILES)
300 @file{stepmake/generic-targets.make} contains lots of rules - too
301 many to list here - it seems to be the main file for rules. (FWIW
302 I haven't actually found a rule for website: anywhere, although
303 it clearly exists. I have also found that you can display a rule
304 in the terminal by typing, say @code{make -n website}. This is
305 probably common knowledge.
307 @file{stepmake/toplevel-targets.make} adds a load of other (and
308 occasionally the same) rules to the gernric-targets.
310 @file{stepmake/po-targets.make} is rules for po* makes.
312 @file{stepmake/install-targets.make} has rules for local-install*.
314 And that's the end of stepmake.make. Back to
315 @file{GNUmakefile.in}. More some other time.
317 Another alterative approach to understanding the website build
318 would be to redirect @code{make -n website} and @code{make website}
319 to a text file and work through a) what it does and b) where the
320 errors are occurring.
322 GP: wow, all the above is much more complicated than I've ever
323 looked at stuff -- I tend to do a "back first" approach (where I
324 begin from the command-line that I want to modify, figure out
325 where it's generated, and then figure out how to change the
326 generated command-line), rather than a "front first" (where you
327 begin from the "make" command).
334 * Building a bibliography::
337 @node Building a bibliography
338 @subsection Building a bibliography
340 Bibliography files contain a list of citations, like this:
344 author = @{Vinci, Albert C.@},
345 title = @{Fundamentals of Traditional Music Notation@},
346 publisher = @{Kent State University Press@},
351 There are a variety of types of citation (e.g. Book (as above),
352 article, publication). Each cited publication has a list of
353 entries that can be used to identify the publication.
354 Bibliograpies are normally stored as files with a .bib
355 extension. One part of the doc-build process is transforming the
356 bibliography information into @code{texinfo} files. The commands
357 to do this are in the @file{GNUmakefile} in the
358 @file{Documentation} directory.
360 A typical line of the makefile to translate a single bibliography
364 $(outdir)/colorado.itexi:
365 BSTINPUTS=$(src-dir)/essay $(buildscript-dir)/bib2texi \
366 -s $(top-src-dir)/Documentation/lily-bib \
367 -o $(outdir)/colorado.itexi \
368 $(src-dir)/essay/colorado.bib
374 $(outdir)/colorado.itexi:
377 We're making the file @file{colorado.itexi} and so this is the
381 BSTINPUTS=$(src-dir)/essay $(buildscript-dir)/bib2texi \
384 It's in the @file{essay} directory and we want to run the
385 bib2texi.py script against it.
388 -s $(top-src-dir)/Documentation/lily-bib \
391 The style template is @file{lily-bib.bst} and is found in the
392 @file{Documentation} directory.
395 -o $(outdir)/colorado.itexi \
398 The output file in @file{colorado.itexi}.
401 $(src-dir)/essay/colorado.bib
404 The input file is @file{colorado.bib} in the @file{essay}
407 The @code{bib2texi} Python script used to be used with a variety
408 of options, but now is always called using the same options, as
409 above. Its job is to create the file containing the options for
410 @code{bibtex} (the program that actually does the translation),
411 run bibtex, and then clean up some temporary files. Its main
412 "value add" is the creation of the options file, using this code:
415 open (tmpfile + '.aux', 'w').write (r'''
418 \bibstyle@{%(style)s@}
419 \bibdata@{%(files)s@}''' % vars ())
422 The key items are the style file (now always lily-bib for us) and
425 The style file is written in its own specialised language,
426 described to some extent at
429 @uref{http://amath.colorado.edu/documentation/LaTeX/reference/faq/bibtex.pdf}
432 The file @file{lily-bib.bst} also has fairly extensive commenting.
435 @section Website build
437 Start here: @file{make/website.make}
439 The overall build system begins with @ref{How stepmake works}.
441 However, we do believe that note that *none* of the variables that
442 are loaded (from depth to version numbers to whatever) are used in
443 @file{website.make}. Instead, @file{website.make} sets up its own
444 variables at the top of the file. If you're wondering if there's
445 some smart reason for this, then the answer is "no". It's because
446 I didn't know/trust the original variables when I was writing that
450 Website build includes @ref{Building a bibliography}.
453 @subsubheading website.make variables
455 The file begins by setting up some variables. These
456 may/might/probably mirror existing variables, but lacking any docs
457 about those variables, I thought it would be simpler to keep
458 everything in the same file.
460 Note that for security reasons, we *don't* call scripts in the git
461 dir when building on the web server. See @ref{Uploading and
462 security}. So we definitely want to keep those definitions for
463 the WEBSITE_ONLY_BUILD.
465 After some split WEBSITE_ONLY_BUILD vs. normal build definitions,
466 there's another bunch of lines setting up generic variables.
468 @subsubheading website.make building parts
470 The website-version rule creates files that define macros for
471 commands like @@stableDocsNotationPdf@{@}, by calling python scripts.
472 Those scripts are scripts/build/create-version-itexi.py and
473 scripts/build/create-weblinks-itexi.py.
475 website-xrefs: creates files used for complicated "out-of-build"
476 references. If you just write @@ref@{@}, then all's groovy. But
477 if you do @@rlearning@{@}, then our custom texi2html init file
478 needs to know about our custom xref file format, which tells our
479 custom texi2html init file how to create the link.
481 We should have a separate @@node to discuss xrefs. Also, take a
482 quick look at a generated xref file -- it's basically just a list
483 of @@node's [sic teenager pluralization rule] from the file.
485 website-bib: generates the bibliography texinfo files from the
488 website-texinfo: this is the money shot; it calles texi2html to
489 generate the actual html. It also has a ton of options to
490 texi2html to pass info to our custom init file.
492 After texi2html, it does some black magick to deal with
493 untranslated nodes in the translations. Despite writing that
494 part, I can't remember how it works. But in theory, you could
495 figure it out by copy&pasting each part of the command (by "part",
496 I mean "stuff before each | pipe"), substituting the variables,
497 then looking at the text that's output. For example,
499 is going to print a list of all html files, in all languages, in
500 the build directory. Then more stuff happens to each of those
501 files (that's what xargs does).
503 website-css: just copies files to the build dir.
505 website-pictures, website-examples: more file copies, with an if
506 statement to handle if you don't have any generated
509 web-post: buggered if I know. Apparently it runs the
510 scripts/build/website_post.py file, which despite writing, I
511 can't remember what it does.
513 ok, it adds the "this page is translated in klingon" to the bottom
514 of html pages, and adds the google analytics javascript. It also
515 has hard-coded lilypond version numbers.
517 website: this is the "master" rule. It calls the bits and pieces
518 in order, then copies some extra files around.
521 @node Building an Ubuntu distro
522 @section Building an Ubuntu distro
526 Install ubuntu, reboot
528 Run all updates, reboot if asked
530 Enable src repos, refresh package lists
532 Install LilyPond build deps:
534 sudo apt-get build-dep lilypond
537 Install git and autoconf:
539 sudo apt-get install git-core gitk autoconf
543 TEST TO SEE WHETHER EVERYTHING WORKS NOW:
546 Use lily-git.tcl to grab source files
548 Go to source dir and do "./autogen.sh" ; make ; make doc
550 If all compiles, move on to iso creation...
555 Download & install "remastersys":
557 http://sourceforge.net/projects/remastersys/
560 Copy lily-git.tcl script file into /etc/skel/
562 Modify /etc/remastersys.conf as desired (change .iso name, default
563 live session username, etc)
565 Remove non-essential desktop software as desired
567 Create iso: sudo remastersys dist
569 New iso is in /home/remastersys/remastersys/
571 Test iso by installing in VM and repeating steps above for
572 getting source files and building lp and docs