Welcome back. In this video we'll be talking about how to create a build system to simplify and improve our process of building a software target. The process software teams used to create a software product using a lot of tools to build, test, and version and develop code. Teams usually consist of many engineers trying to build software in a similar or consistent way. However this process can be very tedious. So far, we have learned that there are numerous commands and many flags that are needed for our advanced use of the command line tools. To memorize all of these options is not feasible. Next, software companies and projects usually support multiple build targets and architectures, both of which affect how we build. Now the concern has to do with the large number of source files a typical software project will contain. Let's look at the example of the Linux Kernel. This software repository contains over 40,000 software files involved in the built process. It is because of these reasons and more that the process of iteratively building a file by file is not scalable for large teams or software rebus. A chance for human error to produce inconsistent builds increases greatly as developers are spending more time in generating builds and less time in development. If we compare these concerns with our IDE build process, we do not see any differences. Behind the scenes the IDE is running any other same compile commands for every single source file you have added to your project and each with many options. Each compile or link command that is issued takes hundreds of characters with over ten flags. Luckily there are tools that hep simplify both command line and IDE building with the help of build automation using make. Build management software functions to provide a simple mechanism to control and build consistent target executable images for your software applications. Build management, build generation and build automation are all terms that can be used in a changibly to meet this function. As you recall,the build system in campuses the process of preprocessing, assembling,compiling,linking and relocating. No difference from our previous tool use is our build generation to our use make Make is yet another free tool we get from the GNU tool chain that is utilized from the command line in the exact same way as GCC. It lives in the executable program binaries folder on Linux and has many options just like GCC did. One big difference is that it is not part of the GCC tool chain as it is independent of the Compiler or the architecture you're using. Therefore there is no arm-none-eabi prefix to the command. This is a good thing since it provides more examples of software abstraction and independence for our course as we want to build a tool that can support many types of compilers and architectures. The GNU Makers formally defined as a tool that controls generation of executables and non-source files of a program, from the program source files. This is very important because we can use GNU Make to do more than just compile but also generate software dependencies, statistical information and many other items. Best of all it's free. Careful and educated use of this tool can help you create an extremely consistent software built With very low developer time for compiling. Let's look at applying Make to a typical GNU Toolchain and the software development environment. GNU Make can be thought of as an extraction interface to building. You still have all your source files, your linker file and libraries. You still need to produce an executable image. What major difference here is the use of one or more Makefiles. This Makefile provide special directions and procedures to make in order to create an executable file from a multitude of input files. Each make file contains specific recipes for building particular targets. These recipes usually have some dependencies and produce some type of output. Think of including header files and C files as dependencies for a recipe to build a particular object file. These dependencies can be auto-generated and output to .dep or .d files automatically by make. In order to build a particular target, you can do so if it's a symbol of two words at the command line. This method of building is similar to scripting. We could invoke make and we can execute many define targets with just the single command. Each target can follow a particular recipe depending on how you defined your targets. Typical targets you might see are direct object partilation, complete build and a clean which removes all generated files Make can be configured to use whichever Complier Toolchain and build process of your choosing. You could use vendor provider toolchains or continue to use GCC as the toolchain with the same process to generate files that we did with our five steps of building. Make could even be configured to support multiple versions of a compiler or even multiple compilers with the same Makefile. Further, the same object files, Dependency Files and Map File can output from the process of Make with careful structure of your Make system. You might be asking, how does the command-line Make system differ from what we did with our integrated development environments? A fundamentally did the exact same thing IDEs provide multiple Makefiles filled with many options and targets. And they compile many source files producing an executable output file. The one difference in writing our own Makefiles versus using an IDE is that the IDE is going to auto-generate their Makefiles depending on how you configured your software project. Meaning it will generate all of the specific flags and linker files for the guards to your architecture. This is good for parading a very simple interface for developers wanting to start fast. But very bad for maintainability and portability. Most software teams implement their own make system, and version control, so they have a method of controlling when a portable, consistent build system, that can work over a variety of architectures of their own design. Here we have a short demo on how simple make is used. In the following video's I'll go into details about what is exactly happening because of that makefile. But we're going to keep this demo simple. Listing all the files in this directory see that we have three sources, two headers and two Makefiles. One Makefile is used as our main Makefile and the other is used to track what are target source files are. This makefile supports a small set of targets including all clean and individual file built. Each of these build files that are associated with that build process or recipe when you run them and this is listed inside the make file. In addition, I provide inside this make file a subset of options to run with each of these GCC commands. If I run make all, this will perform a complete build to create an executable output file. The term all which uses an arbitrary name for a compile all type of target. As you can see all individual compile command were run for each file. In addition a final link command was run. We can see that the current directory now contains of these output files from the build process. Next I'll run make clean command. Which will remove all of my generated files, thus cleaning my build directory from all of my non-source files. This will run a basic remove command that deletes all of the generated files. You must be careful with how you implement clean, because you do not want it to remove source files or other important files. After running this the director has been cleaned. Last we can also define our build targets to run individual build files like the generation of the main.o object file. We could do this by running make main.o, as you can see only a single command was issued for the build and all the appropriate command options were put in there. Leaving in this folder a single main.o file. Built systems are very important for software teams. Without them, the process of creating a complex target executable would be very tedious and error prone for typical developer. There are many build generation systems out there besides make but make is still widely used today. Build systems allow for abstraction from the target software and architecture, so that they are portable and can be added to version control. This provides a mechanism for teams to create consistent builds over time without loosing any information about what the configuration of their build was. Next, we will look into how to create our own name files. [BLANK_AUDI O]
