|  | Build Framework | 
|  | =============== | 
|  |  | 
|  | The perf build framework was adopted from the kernel build system, hence the | 
|  | idea and the way how objects are built is the same. | 
|  |  | 
|  | Basically the user provides set of 'Build' files that list objects and | 
|  | directories to nest for specific target to be build. | 
|  |  | 
|  | Unlike the kernel we don't have a single build object 'obj-y' list that where | 
|  | we setup source objects, but we support more. This allows one 'Build' file to | 
|  | carry a sources list for multiple build objects. | 
|  |  | 
|  |  | 
|  | Build framework makefiles | 
|  | ------------------------- | 
|  |  | 
|  | The build framework consists of 2 Makefiles: | 
|  |  | 
|  | Build.include | 
|  | Makefile.build | 
|  |  | 
|  | While the 'Build.include' file contains just some generic definitions, the | 
|  | 'Makefile.build' file is the makefile used from the outside. It's | 
|  | interface/usage is following: | 
|  |  | 
|  | $ make -f tools/build/Makefile.build srctree=$(KSRC) dir=$(DIR) obj=$(OBJECT) | 
|  |  | 
|  | where: | 
|  |  | 
|  | KSRC   - is the path to kernel sources | 
|  | DIR    - is the path to the project to be built | 
|  | OBJECT - is the name of the build object | 
|  |  | 
|  | When succefully finished the $(DIR) directory contains the final object file | 
|  | called $(OBJECT)-in.o: | 
|  |  | 
|  | $ ls $(DIR)/$(OBJECT)-in.o | 
|  |  | 
|  | which includes all compiled sources described in 'Build' makefiles. | 
|  |  | 
|  |  | 
|  | Build makefiles | 
|  | --------------- | 
|  |  | 
|  | The user supplies 'Build' makefiles that contains a objects list, and connects | 
|  | the build to nested directories. | 
|  |  | 
|  | Assume we have the following project structure: | 
|  |  | 
|  | ex/a.c | 
|  | /b.c | 
|  | /c.c | 
|  | /d.c | 
|  | /arch/e.c | 
|  | /arch/f.c | 
|  |  | 
|  | Out of which you build the 'ex' binary ' and the 'libex.a' library: | 
|  |  | 
|  | 'ex'      - consists of 'a.o', 'b.o' and libex.a | 
|  | 'libex.a' - consists of 'c.o', 'd.o', 'e.o' and 'f.o' | 
|  |  | 
|  | The build framework does not create the 'ex' and 'libex.a' binaries for you, it | 
|  | only prepares proper objects to be compiled and grouped together. | 
|  |  | 
|  | To follow the above example, the user provides following 'Build' files: | 
|  |  | 
|  | ex/Build: | 
|  | ex-y += a.o | 
|  | ex-y += b.o | 
|  | ex-y += b.o # duplicates in the lists are allowed | 
|  |  | 
|  | libex-y += c.o | 
|  | libex-y += d.o | 
|  | libex-y += arch/ | 
|  |  | 
|  | ex/arch/Build: | 
|  | libex-y += e.o | 
|  | libex-y += f.o | 
|  |  | 
|  | and runs: | 
|  |  | 
|  | $ make -f tools/build/Makefile.build dir=. obj=ex | 
|  | $ make -f tools/build/Makefile.build dir=. obj=libex | 
|  |  | 
|  | which creates the following objects: | 
|  |  | 
|  | ex/ex-in.o | 
|  | ex/libex-in.o | 
|  |  | 
|  | that contain request objects names in Build files. | 
|  |  | 
|  | It's only a matter of 2 single commands to create the final binaries: | 
|  |  | 
|  | $ ar  rcs libex.a libex-in.o | 
|  | $ gcc -o ex ex-in.o libex.a | 
|  |  | 
|  | You can check the 'ex' example in 'tools/build/tests/ex' for more details. | 
|  |  | 
|  |  | 
|  | Makefile.include | 
|  | ---------------- | 
|  |  | 
|  | The tools/build/Makefile.include makefile could be included | 
|  | via user makefiles to get usefull definitions. | 
|  |  | 
|  | It defines following interface: | 
|  |  | 
|  | - build macro definition: | 
|  | build := -f $(srctree)/tools/build/Makefile.build dir=. obj | 
|  |  | 
|  | to make it easier to invoke build like: | 
|  | make $(build)=ex | 
|  |  | 
|  |  | 
|  | Fixdep | 
|  | ------ | 
|  | It is necessary to build the fixdep helper before invoking the build. | 
|  | The Makefile.include file adds the fixdep target, that could be | 
|  | invoked by the user. | 
|  |  | 
|  |  | 
|  | Rules | 
|  | ----- | 
|  |  | 
|  | The build framework provides standard compilation rules to handle .S and .c | 
|  | compilation. | 
|  |  | 
|  | It's possible to include special rule if needed (like we do for flex or bison | 
|  | code generation). | 
|  |  | 
|  |  | 
|  | CFLAGS | 
|  | ------ | 
|  |  | 
|  | It's possible to alter the standard object C flags in the following way: | 
|  |  | 
|  | CFLAGS_perf.o        += '...'  - adds CFLAGS for perf.o object | 
|  | CFLAGS_gtk           += '...'  - adds CFLAGS for gtk build object | 
|  | CFLAGS_REMOVE_perf.o += '...'  - removes CFLAGS for perf.o object | 
|  | CFLAGS_REMOVE_gtk    += '...'  - removes CFLAGS for gtk build object | 
|  |  | 
|  | This C flags changes has the scope of the Build makefile they are defined in. | 
|  |  | 
|  |  | 
|  | Dependencies | 
|  | ------------ | 
|  |  | 
|  | For each built object file 'a.o' the '.a.cmd' is created and holds: | 
|  |  | 
|  | - Command line used to built that object | 
|  | (for each object) | 
|  |  | 
|  | - Dependency rules generated by 'gcc -Wp,-MD,...' | 
|  | (for compiled object) | 
|  |  | 
|  | All existing '.cmd' files are included in the Build process to follow properly | 
|  | the dependencies and trigger a rebuild when necessary. | 
|  |  | 
|  |  | 
|  | Single rules | 
|  | ------------ | 
|  |  | 
|  | It's possible to build single object file by choice, like: | 
|  |  | 
|  | $ make util/map.o    # objects | 
|  | $ make util/map.i    # preprocessor | 
|  | $ make util/map.s    # assembly |