Episode: 2107 Title: HPR2107: Makefiles for Everyday Use Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2107/hpr2107.mp3 Transcribed: 2025-10-18 14:23:34 --- This is HPR episode 2107 entitled Make Files for Everyday Use. It is hosted by John Colp and in about 23 minutes long. The summary is, I talk about how I use Make Files in my lilicond and HTML projects. This episode of HPR is brought to you by an honesthost.com. Get 15% discount on all shared hosting with the offer code HPR15. That's HPR15. Better web hosting that's honest and fair at An Honesthost.com. Hey everybody, this is John Colp and I've had Louisiana recording another show for Hacker Public Radio. I think I can get one more of these in before the semester kicks off for real on Monday. First before I get started, I want to thank the person who reached out to me this morning to ask whether I and my family are okay. You may or may not be aware that we've had very severe flooding right here in my region because of a storm that just got stalled out over us about a week ago. I think it was last Friday that it really started raining really hard and it rained hard for a really long time and a storm just didn't move through and it flooded quite a lot of areas in our neighborhood. My kids have been off of school for the entire week because of all the flooding. Be personally or fine, my house was not seriously threatened by the flooding, although it got a whole lot closer than I ever thought it could. My house is on top of a little hill, it's not like we're really on a hill, but from the back of my house going down, I have a yard that goes down maybe 100 feet or so in length and in elevation change it's maybe 12 or 15 feet from my porch all the way down to the bottom of the yard. I thought we would never ever have to worry about flooding being that high up and there's a drainage ditch that runs behind my house where when there's a heavy rain the purpose of the ditch is to funnel all the rain into the river which is downstream, I don't know, a mile or so. Well there was so much rain that the water got about six feet deep in my backyard and that's about, I don't know, five and a half feet deeper than it's ever gotten before and so I was really getting concerned there for a while because at the time it got the deepest it had not stopped raining yet and I thought well man if it keeps raining like this it really could get all the way up here and come into my house but thankfully it stopped raining, the water receded and the ditch behind my house is still completely full and normally it's empty but you know the water is receding gradually but there are areas where houses are still two feet deep in water, a couple of my faculty have our homeless now because their houses were over flown two to three feet deep in water, the cars were destroyed and it's a bad deal so I really appreciate the person who reached out and asked how we are doing, we personally are fine but the region is in bad bad shape so we're hoping the recovery will be speedy but it might not be, it could take a while, anyhow. The topic that I wanted to talk about today is one that's been on my HPR2 do list for quite a long time and I thought it was time to do this because the queue is getting kind of low, I think when I record this and post it I will have like only a week before my turn comes up so that we really need more shows and if nothing else I think this show will provide impetus for other people to contribute shows because I'm talking about a topic that I don't really know a whole lot about and so I'm going to mess things up which will hopefully be just the prompt that a lot of the experts out there need to respond with their own shows where they set me straight, okay so that's a challenge y'all, figure out what I messed up and then respond with your own show to set everybody on the right path. So what I'm going to talk about is make files, if you've ever built anything from source code you know that you often have to type a command, make all or make something and if you've never looked inside the make file you might not really know what's going on, you just know you type that command and then a whole bunch of crazy stuff starts happening and hopefully at the end of it you've built your program and you can install it and run it. Well you can also do make files for other things, the title of the episode is make files for everyday use and the only way I use make files is with the various HTML projects that I do or with some of my more complicated lily pond project. So I'm a composer or I haven't written anything in a while but I've written quite a lot of pieces of music and I use lily pond as my notation editor and lily pond is unusual for notation editors in as much as you essentially write computer code that is then compiled and output as PDF or MIDI or PNG files or things like that but you're starting with source code and you're compiling it and so it actually makes quite a lot of sense to use a make file. Most simple lily pond files don't require make files, you just type the command lily pond followed by space followed by your lily pond source file and then it will do what you want. However, there are some projects when they get large and have lots and lots of dependent files and things like that sometimes it can really help to use a make file to keep track of everything. One example of this is the counterpoint workbook that I wrote in 2009 which is one of these things that combines text and musical examples. So there are paragraphs of text and then there are scores of music interspersed in there and I used a part of the lily pond code called lily pond book which is essentially a big long Python file but it allows you to combine freely La Tech and lily pond in such a way. So you're using the La Tech spilled latex which is great for document processing especially in the sciences where you have to do complicated formulas and things like that. Well you can use La Tech and lily pond code in such a way that you get these beautiful books with text and musical examples interspersed and it works wonderfully. Once you've got a set up it works wonderfully. It can be a little bit difficult to make it compile the first time and the commands are kind of long and have many options and specifications for output files and things like this. So I found pretty quickly once my counterpoint project got going that I needed a make file to keep track of it or else I would never get it done. And so I created, I think that was my very first make file was for the counterpoint workbook and I've put it in the show notes so that everyone can see. And essentially what you do with a make file is you store the commands that can be very complicated and you tell it, you give it some targets so you can say make and then you have various targets. One of the targets is all and then you can specify whatever targets you want. I have a target called PDF, I have a target called web, I have a target called keep and another target for a clean up called clean. So when you type make clean it completely deletes the build directory. And then there's another one, a make archive which will run a series of commands to create tar balls excluding the output files and things like that that are not actually part of the source code for the book. And then it creates both a tar and a zip file and saves them in a nice safe location. And so at the top of the make file is where you can put various variables that you want to use and so in the one that I have here, the first thing is I tell it which shell I'm going to use slash bin slash bash. And then I tell it what the main file is that I'm working on and it's workbook underscore main. And then I give the name of an output directory called out and then my web output directory is html out. And then some kind of optional things, I give it a viewer, viewer equals events, browser equals Firefox. And then this is next where I start putting together some commands. So the first command is lilybook pdf. So lilypon book can output in different formats. One of the, I mean the one I wanted mainly for the workbook was pdf and it runs a slightly different command than if you're doing html output for example. So I do lilybook underscore pdf equals lilypon hyphen book space double dash output equals dollar sign open parenthesis out there close parenthesis. And so that's substituting in the value that I gave just above for the output directory. And then there's a space, another double dash pdf which tells it the output format to do space dollar sign open parenthesis file. And that tells it the, it substitutes in there the variable workbook underscore main. Close parenthesis dot LYTEX light text is the extension I use for the lot tech files that are going to be incorporating lilypon code in them. And in these light text file, LYTEX files, I don't usually put the lilypon code directly there. I use includes. And so at the right point for an example it says to include the lilypon file that is located at the path specified there. And so there end up being lots and lots of dependent files. And this, this make file is a little simpler than some of the other ones that you might make because the lilypon book script itself actually has components in there that keep track and will check to see whether files have been changed and to see whether it needs to actually compile anything or not. In the example I'm going to look at next, I'll show you how you can tell it when I make a pdf, you need to check all of the files with these extensions or these two specific files. If it changes, then yes, you build it. If there are no changes to those files, then no, don't bother. So anyway, I set up a lilybook pdf command and then right below that there's an HTML command for if I'm running it in HTML. And then I have another command called pdf which will change into the output directory and then run the pdf lot tech command on the file there. For if I'm doing HTML, I cd to the web output directory and run the lot tech to HTML command on the file. There's also a function in lot tech where you can make an index and so it will also check to see whether the index needs to be run and will make that. So that has to cd into the output directory and then run the make index command on the file. And if I've added any new references in the book, you know, footnotes and whatnot or a new index, actually the bibliography is a different, the lot tech can also do bibliography is really wonderfully, that's a separate thing I got confused there for a moment. The index is where during the text of your lot tech file, you can tell it, please use this word as part of the index and it will automatically add the word to your index at the end of the book until which page it's referred to on, it's really, really smart that way. So then my target for all, so when you type make all, it will do both pdf and web. You can also type make pdf and if you do that, it will do the lily pond book pdf commands. It will rerun the index, it will make the pdf and then it will open up the result in the events pdf viewer on Linux. The web target has it run the lily book html version of the command and then it moves all of the web files over into a certain directory and then it looks like, it's been a long time since I did this, but it looks like for the web version there is a said script that I run on the output to fix a few things. It probably adds some lines to the html header section to, I think what I did was I added a few lines up there in the header to make it mobile friendly and stuff like that. Then the make keep target will take the pdf file that was generated in the pdf command and then rename it and move it into the top directory and also update the pdf info, like the metadata. There are some errors in the metadata that make it so that the table of contents in the pdf is all jacked up and so I run a little update info thing on the pdf using pdf tk. That makes a nice clean pdf with a table of contents just how I want it. And then there is clean and web clean and archive and so forth. So I have another example in the show notes for one of my Lillipond projects for a song cycle that I wrote called Cancioni Spada NiƱos and I've got a songs for children based on poems by Federico Garcia Lorca and I will have a link to the web page on my website where you can actually listen to all the songs if you want to and I think I may even have the Lillipond source files up there. But this one, so there are nine songs in the collection and using the make file I can compile any single song from the collection or if I type make score it will do the entire collection as one big pdf. And as far as the individual songs each one has its own .ily file so the extension is ily for a Lillipond include file and I keep only the notes for the song right there. I separate the notes from the building of the score so that it's more flexible and that allows me using the same source file for the notes I can either compile the entire score of nine songs or the one song individually. So I have a variable called notes equals and then I list all of the .ily files that there are for the nine songs and then here comes some things that I don't understand and these things would help if an expert will come in and do a show about it. There is something called .suffixes and I guess that's where I define all of the various suffixes that are going to appear in the make file and I have four of them here .ily.ily.ily. These are the two Lillipond related ones and the .ily file will be like the main Lillipond file and then in the top of the Lillipond file if there is a separate file where the notes are stored it'll say include the .ily file here. Then there is .pdf and .mitty so I've got mitty files pdf and then two kinds of Lillipond files and so those suffixes are included it's kind of like a manifest I guess to show that these things are going to be used in this make file. Then there is a v-path variable where I think there are a couple of like GNU make standard variables here. Curder, C-U-R-D-I-R and v-path I think both of those are things that are standard in make. I don't really know. Again, we need expert opinions on this. Then there is a section where the commands to be run are defined. So if any Lillipond file, let me see here, okay I think I know what's happening here. Here is where I define which files are kind of dependent on which others. So for any Lillipond file name that is given, it checks to see whether anything has changed in the notes file, the ILY file that has the same stem, you know, the main part of the name, the file name. And then, so the way that's done is it says percent sign dot LY colon space, percent sign dot ILY. And my understanding is that means that whenever you're using an LY file, check to see if any changes have been made to the ILY file having the same name. And then if there are changes, then you compile. So then I have, the next line says percent sign dot PDF, space, percent sign dot MIDI colon. So if you're trying to create PDFs or MIDI files, it says then to check the LY files to see whether they need to be rerun again. And then if they do, then it will run the Lillipond command that has been defined at the top of the score, which is kind of along with it's Lillipond space, dash, D delete, hyphen intermediate, hyphen files, space dot D, no hyphen point, hyphen and hyphen click. So it's kind of a long command. And that just sets a couple of the command line parameters that are optional that I like to have on this. So down here where it runs, I'm sorry, you really need to look at this while I'm talking or else you're not going to understand anything I'm saying. But it runs the Lillipond command on whatever file was given as the first command line argument. And then it moves the PDF output into a PDF directory and then it moves the MIDI output over into a MIDI directory. So then on the next line down, I say, if PDF is your target, then you need to check whether there have been any changes in any of the notes files. And if so, then it runs. And then I have a list of all nine songs individually. So the first song PDF file is dependent on both the LY and the ILY versions, files that created. And so if I were to type, so one of the songs name is lagarto.pdf. So if I type make lagarto.pdf, it will check to see whether lagarto.ly or lagarto.ly have had any kind of changes. And if so, it will build it. If not, it'll say nothing to do for this. It's already done. So next down, the next line down is another one of these things that to me is very obscure and an expert would be able to tell me what this means. I just know that without it, it doesn't seem to work right. This dot phony dot pho ny colon. And after that is the word score. And then on the next line, I have my target score. So the score target is the main piece file dot pdf. And I wish I understood better how this whole thing works, but this is one of those things. I learned just enough to be able to create my make file where it worked exactly how I wanted it. And then I've never thought about it again since then. So then the make keep target says that if I type make keep, it builds the score. And then it copies the output file into the top directory and renames it into a more human readable name. And then there's also a make archive target where it runs a tar command to create a tar ball, excluding the compiled parts of it like the pdf and the midi and so forth. And then it will untar it and make a zip file of the same thing so that it creates both a tar and a zip file for that. And that's something. So that if I want to do the make archive command, it will run all those things and give me a zip or a tar file that I can easily share with someone else who might want to build the songs. Anyway, in this case, an example is probably worth a thousand words so I really encourage you to go and look at the show notes to see these examples and try, if you've got any kind of project where you're keeping track of numerous different text files and having to build them, then it's worth giving it a try, doing a make file to see if it will help easier burden. All right, I guess that's about it. Again, I really hope someone will do or follow up episode and explain some of the stuff that I don't understand. Thanks, y'all. I will talk to you again later. Bye. You've been listening to Hacker Public Radio at Hacker Public Radio dot org. We are a community podcast network that releases shows every weekday, Monday through Friday. Today's show, like all our shows, was contributed by an HPR listener like yourself. If you ever thought of recording a podcast and click on our contributing to find out how easy it really is, Hacker Public Radio was founded by the digital dog pound and the infonomicum computer club and is part of the binary revolution at binwreff.com. If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself. Unless otherwise status, today's show is released on the create of comments, attribution, share a like, free dot org license.