This week’s question comes from Scott S. who wants to know what are all the files that get created when building an application.
Here are the file types that the podcast lists:
- Log files (*.log)
- Object files (*.obj, *.o)
- Symbol files (*.pdb)
- Incremental files (*.ilk)
- Executable files (*.exe)
- Library files (*.lib, *.a, *.dll, *.so)
Listen to the full episode or read the full transcript below.
Transcript
The thing I like best about this question is that you have to start programming before you realize that this even exists. If all you’re doing is listening to this podcast or reading books about programming, you might think that you’re learning. But you’re not. You need to be doing. Take action. Even if your first program just says “Hello” like Scott’s, you’ll then have something that you took from beginning to end. That’s awesome!
Once you have that, poke around a bit and explore. Try to run your application in different ways. Try to build your application with different settings. And pay attention to details. If you see anything that you don’t understand, the first thing you should do is try to figure it out yourself. Get in the habit of trying to solve a problem. If you still need help, then definitely, ask.
If you do this, then you’ll get so much more from the answer. Your question and then the answer will start a dialog where you will gain insight into the nuances that you haven’t thought about yet.
If instead, you just ask without trying to figure out your question on your own, then you’ll get an answer sure. But it won’t mean as much. And you might even forget it a short while later. But you know what? Even this is better than the alternatives of not doing anything at all or doing something but keeping your questions bottled up.
The way to learn is to be curious, explore, and ask for help when needed. And if you want to take your learning to a whole new level, try to explain what you’ve learned to somebody else.
Alright, so back to the question.
The first thing you might notice is a new folder called Debug or Release. When building your application, most integrated development environments or IDEs will allow you to select between Debug and Release configurations. For a simple application, there won’t be much difference between them but this can be useful for a larger application. It will help you find problems easier if you are debugging an application that was built with the Debug configuration. This is because Debug will turn off optimizations that the compiler will use to change your code slightly to make it perform better. That means the running code will exactly match your source code. For larger applications, you can also use a Debug configuration to include extra checks in your code to help you find problems. These checks are not needed when you release your application to customers and will probably slow it down and include extra information that could confuse your customers. When it’s time to release your application, then create a build with the Release configuration. It’s a good idea to test your Release builds regularly if not all the time because this is what your customers will receive. If you find a problem, that’s the time to switch to a Debug configuration to help find the cause. Regardless of which configuration you’re currently building, the extra files will normally be the same.
If you’re using Xcode on a Mac, then you probably won’t see any extra files or folders. This is because Xcode hides its output.
For Visual Studio, you’ll find a Debug or Release folder in your project folder as well as in your solution folder. Most IDEs have separate concepts of a Solution and a Project. A Solution allows you to group together many Projects that are all related. This is up to you to determine if a new Project should be created in one of your existing Solutions or in a new Solution. Some IDEs will call a Solution a Workspace. The idea is the same. It’s just a way to organize your Projects. A project folder is where you put all the files needed to build a specific application.
Some IDEs may have just one Debug or Release folder and you might find it at the Solution or at the Project level. Or if you’re working on a large application at a software company, then you might have custom build scripts that place the output files in a completely different location. The first step is just figuring out where things are going.
So what kinds of files will you find?
- You’ll probably find log files. These files will contain output text and error messages from the compiler tools and will probably end in a .log file extension.
- You’ll find an object file for each of your source files. Compilers translate source files one at a time independently of other source files and produce an intermediate file with the result of that compilation. An intermediate file cannot be run by itself. They all have to be put together by a tool called the linker to get to the final application executable file. Object files have extensions that are different depending on your operating system. For Windows, object files will have a .obj file extension. Other operating systems might use a .o file extension.
- You’ll find files used by the debugger tool and these could have file extensions similar to .pdb. These are database files and contain information that helps the debugger match the running instructions with the source code. It’s really hard to debug an application without these files. They’re sometimes referred to as symbol files.
- You may also find various incremental files. These are used to speed up the process of building an application. The first time you build, it might actually take a bit longer because of these incremental files. But subsequent builds should go faster. These files normally have a file extension that begins with a .i something but that’s not a rule or anything.
- You’ll find your executable file itself with a .exe file extension. That’s assuming of course that your project is for an application. You could also have a project that is not intended to be run directly but to be used by another project. These are usually library projects. The file extension for a library also depends on your operating system and could be a .lib, a .dll, a .a , or a .so file extension.
And large projects or commercial projects will have resource files, image files, sound files, config files, installer files, documentation files, license files, and probably a few others that I’m forgetting. You could also find entire folder structures with cryptic abbreviated names that identify languages and regions.
And of course each programming language will be different with its own set of output files and naming conventions.
You’ll definitely want to take some time to get used to the output files and locations that your development environment produces.