| 失效链接处理 |
|
Android Build System PDF 下载
本站整理下载：
相关截图：
主要内容：
Objective
The primary goals of reworking the build system are (1) to make dependencies work more
reliably, so that when files need to rebuilt, they are, and (2) to improve performance of the
build system so that unnecessary modules are not rebuilt, and so doing a top-level build
when little or nothing needs to be done for a build takes as little time as possible.
Principles and Use Cases and Policy
Given the above objective, these are the overall principles and use cases that we will
support. This is not an exhaustive list.
Multiple Targets
It needs to be possible to build the Android platform for multiple targets. This means:
The build system will support building tools for the host platform, both ones that are
used in the build process itself, and developer tools like the simulator.
The build system will need to be able to build tools on Linux (definitely Goobuntu and
maybe Grhat), MacOS, and to some degree on Windows.
The build system will need to be able to build the OS on Linux, and in the short-term,
MacOS. Note that this is a conscious decision to stop building the OS on Windows.
We are going to rely on the emulator there and not attempt to use the simulator. This
is a requirement change now that the emulator story is looking brighter.
Non-Recursive Make
To achieve the objectives, the build system will be rewritten to use make non-recursively.
For more background on this, read Recursive Make Considered Harmful. For those that
don't want PDF, here is the Google translated version. Rapid Compile-Test Cycles
When developing a component, for example a C++ shared library, it must be possible to
easily rebuild just that component, and not have to wait more than a couple seconds for
dependency checks, and not have to wait for unneeded components to be built.
Both Environment and Config File Based Settings
2020/12/29 Android Build System
file:///Z:/ssd/qcm2290/build/core/build-system.html 2/17
To set the target, and other options, some people on the team like to have a configuration
file in a directory so they do not have an environment setup script to run, and others want
an environment setup script to run so they can run builds in different terminals on the
same tree, or switch back and forth in one terminal. We will support both.
Object File Directory / make clean
Object files and other intermediate files will be generated into a directory that is separate
from the source tree. The goal is to have make clean be "rm -rf " in the tree root directory.
The primary goals of this are to simplify searching the source tree, and to make "make
clean" more reliable.
SDK
The SDK will be a tarball that will allow non-OS-developers to write apps. The apps will
actually be built by first building the SDK, and then building the apps against that SDK. This
will hopefully (1) make writing apps easier for us, because we won't have to rebuild the OS
as much, and we can use the standard java-app development tools, and (2) allow us to
dog-food the SDK, to help ensure its quality. Cedric has suggested (and I agree) that apps
built from the SDK should be built with ant. Stay tuned for more details as we figure out
exactly how this will work.
Dependecies
Dependencies should all be automatic. Unless there is a custom tool involved (e.g. the
webkit has several), the dependencies for shared and static libraries, .c, .cpp, .h, .java, java
libraries, etc., should all work without intervention in the Android.mk file.
Wildcard source files
Wildcarding source file will be discouraged. It may be useful in some scenarios. The default
$(wildcard *) will not work due to the current directory being set to the root of the build tree.
Multiple targets in one directory
It will be possible to generate more than one target from a given subdirectory. For
example, libutils generates a shared library for the target and a static library for the host.
Makefile fragments for modules
Android.mk is the standard name for the makefile fragments that control the building of a
given module. Only the top directory should have a file named "Makefile".
Use shared libraries
Currently, the simulator is not built to use shared libraries. This should be fixed, and now is
a good time to do it. This implies getting shared libraries to work on Mac OS.
|
| Java1234官方群25： | 
|
| Java1234官方群25： | 838462530 |
苏公网安备 32061202001004号
