QA Friday 2015-Nov-20

Take Up Code - A podcast by Take Up Code: build your own computer games, apps, and robotics with podcasts and live classes

Categories:

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 S