An build.mk file is written to describe your sources to the build system. More
specifically:
The file is really a tiny GNU Makefile fragment that will be parsed one or
more times by the build system. As such, you should try to minimize the
variables you declare there and do not assume that anything is not defined
during parsing.
The file syntax is designed to allow you to group your sources into
'modules'. A module is one of the following:
o a static library
o a shared library
o a executable
You can define one or more modules in each build.mk file, and you can use
the same source file in several modules.
The build system handles many details for you. For example, you don't need
to list header files or explicit dependencies between generated files in
your build.mk. The build system will compute these automatically for you.
This also means that, when updating to newer releases of the XBuild, you
should be able to benefit from new toolchain/platform support without having
to touch your build.mk files.
Simple example:
Before describing the syntax in details, let's consider the simple "hello"
example, assume the structure of "hello" project is following:
o The 'src' directory containing the c source for the sample project.
o The 'include' directory containing the c header file for the sample project.
o The 'hello/build.mk' file that describles the sub diretory to build system.
Its content is:
---------- cut here ----------
include $(all-subdir-makefiles)
---------- cut here ----------
o The 'src/build.mk' file that describles the shared library to build system.
Its content is:
---------- cut here ----------
$(call prepare-build)
Overview
An build.mk file is written to describe your sources to the build system. More
specifically:
The file is really a tiny GNU Makefile fragment that will be parsed one or
more times by the build system. As such, you should try to minimize the
variables you declare there and do not assume that anything is not defined
during parsing.
The file syntax is designed to allow you to group your sources into
'modules'. A module is one of the following:
o a static library
o a shared library
o a executable
You can define one or more modules in each build.mk file, and you can use
the same source file in several modules.
The build system handles many details for you. For example, you don't need
to list header files or explicit dependencies between generated files in
your build.mk. The build system will compute these automatically for you.
This also means that, when updating to newer releases of the XBuild, you
should be able to benefit from new toolchain/platform support without having
to touch your build.mk files.
Simple example:
Before describing the syntax in details, let's consider the simple "hello"
example, assume the structure of "hello" project is following:
hello
├─include
│ └─hello.h
├─src
│ ├─build.mk
│ └─hello.c
└─build.mk
Here, we can see:
o The 'src' directory containing the c source for the sample project.
o The 'include' directory containing the c header file for the sample project.
o The 'hello/build.mk' file that describles the sub diretory to build system.
Its content is:
---------- cut here ----------
include $(all-subdir-makefiles)
---------- cut here ----------
o The 'src/build.mk' file that describles the shared library to build system.
Its content is:
---------- cut here ----------
$(call prepare-build)
MODULE := hello
INCLUDES := ../include
CFLAGS := -O3 -Wall -ggdb -D_DEBUG
CPPFLAGS :=
CXXFLAGS := $(CPPFLAGS)
LDFLAGS := -L/usr/local/lib -L/usr/lib
LDLIBS :=
SHARED_LIBS :=
STATIC_LIBS :=
SOURCES := hello.c
$(call build-shared-library)
---------- cut here ----------
Xbuild provided environment variables
ARCH
The architecture of the CPU
PROJECT_PATH
The absolute path of project
Xbuild provided variables
MODULE
This variable is required, it's describled the module name.
INCLUDES
A set of C/C++ header file include directory, for example:
INCLUDES := ../include
INCLUDES += ../../include
CFLAGS
A set of compile flags for .c source file, for example:
CFLAGS := -O0 -Wall -g3 -ggdb -D_DEBUG -fPIC
CPPFLAGS
A set of compile flags for .cpp source file, for example:
CPPFLAGS := -O0 -Wall -g3 -ggdb -D_DEBUG -fPIC -std=gnu++0x
CXXFLAGS
A set of compile flags for .cxx and .cc source file, for example:
CXXFLAGS := -O0 -Wall -g3 -ggdb -D_DEBUG -fPIC -std=gnu++0x
LDFLAGS
A set of link flags for build shared library, static library orcutable,
for example:
LDFLAGS := -L/usr/local/lib -L/usr/lib -L$(call pwd)/../lib
NOTE: If the path is relative, should use the function $(call pwd) to locate
current directory.
LDLIBS
A set of external library to link, for example:
LDLIBS := -lrt -lpthread
SHARED_LIBS
A set of shared library module name that dependencied by current module,
for example:
SHARED_LIBS := module-foo module-bar
If the SHARED_LIBS is defined, the module linked after all of dependency
module linked success.
STATIC_LIBS
A set of static library module name that dependencied by current module,
it's the same of SHARED_LIBS.
SOURCES
A set of source file to compile.
Xbuild provided functions & macros
About the details, please see '$Xbuild/core/definitions.mk'
Usage
The usage of xbuild:
cd <project-directory>
xbuild all [ARCH=x86] [OS=linux] [CC=gcc]</project-directory>
or
xbuild c[lean]
or
xbuild r[ebuild] [ARCH=arm] [OS=linux] [CC=arm-none-linux-gnueabi-gcc]
Last edit: g.johnsonlee@gmail.com 2012-03-25