123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166 |
- 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 += '...' - alters CFLAGS for perf.o object
- CFLAGS_gtk += '...' - alters 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
|