Coding,  Open Source,  Ubuntu,  Uncategorized

Good Practices: Compiling from Source #2

I went over the first part of compiling (configuring) in my earlier blog post here.

Easy Make Oven

Now, you’ve successfully configured your project, and you’re ready to build. Thankfully, this step is usually pretty straightforward and simple, all you do is type
and the project should build successfully. The configure step took care of all the heavy lifting for you, and is why we have that configure step!

Although this step is usually pretty foolproof, there are annoyances and frustrations that can pop up.

The Time, man, the Time!

The first annoyance is that this step can take a long long time! I’m still surprised when coders don’t know about
make -j4
which will compile using 4 threads. This speeds up the compile because it will parallelize the compile along the 4 threads. Also as a side note, the make command will only compile files that have been modified since the last compile. This means that the first compile of a project is always the longest. Then if you go and change a few files, it will only re-compile those few files.

Its Rare, but…

The other annoyance that happens rarely is that builds can be broken. This is rare (especially if you’re not touching the code at all), but it does happen. As a matter of fact, its usually a very strict project policy that before any change goes in, it must at least compile. If someone commits something that doesn’t compile, they’re usually reprimanded and suffer a blow to their reputation! That being said, compiling and compile options can be pretty complex, and sometimes (especially if the build has a lot of build options) things won’t compile right.

What I’ve seen happen a few times is that the configure step doesn’t check for a package it actually needs. If you’re a developer who compiles stuff all the time, you’re likely to have the same subset of files on your computer as every other developer, and might have simply forgot something your project needed when the developer was specifying the configure step. If your build is complaining about not being able to find a header file, try to find it with the methods that were specified in my first post.

If its still broken, you can try to check out a slightly older revision. The idea here is that something in the last few developer changes broke the build, and that going back a few small changes will go back to a version that works. After checking out say, 20 commits back in the past, try making the project again. If it works with the older version, but not the new one, that means you’ve found a regression and can probably report it to the mailing list for the project after you’ve pinpointed the regression commit. You’ve just done your part to make the project better!

If checking out a slightly-older version doesn’t work, you should check your steps over and over again. Its never good to enter an open source project’s mailing list archives with a question about how to compile, so you should try very hard to get it to compile yourself. If you’re really stuck, you can reach out to people for help via IRC or email.

The Last Step

Now your build is done! All the files that this project needs to run are now present in your build directory. Sometimes they’re buried in a few directories, but they’re there, and the build system knows where each and every one is. The last step is to install these in a way that it can work on your computer! Thats the next article though, so stay tuned!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.