Error out if there is a file listed in LOCAL_SRC_FILES_EXCLUDE but not in
LOCAL_SRC_FILES. This should catch typos or other mistakes that would
otherwise be missed.
Change-Id: Iaddf575a6ce35238998ac47b59591a7d05fbcd0d
There is currently an intentional incremental rebuild issue with
import_includes. export_includes might get updated with an identical
version, but we don't want to force everything downstream of it to
rebuild.
When BUILDING_WITH_NINJA==true, only update export_includes if it
changes, and use .KATI_RESTAT to only run downstream rules if it
changes. import_includes will only be updated if one of the
export_includes files is updated, so object files can have a normal
dependency on import_includes instead of an order-only dependency.
All downstream object files will now be recompiled if their imported
include paths change.
Bug: 25910568
Change-Id: I626f3b24ac02ac1309049cf1ce66cfe8ec816513
The export_includes file for a library needs to express a dependency on
all generated exported headers. For aidl generated headers, express a
dependency on the .cpp file instead, since the generator promises to
generate this file last. Unfortunately, the C++ headers generated from
a .aidl file depend on the contents of the file.
Change-Id: I9402b364e4538b502c0958ac8c7bd72cb0add724
It is common for developers to generate/compile AIDL in a static
library, then link that library into an executable. When doing this,
developers need to export the generated headers.
Bug: 25779424
Test: a refactoring of the aidl Android.mk shows this works
Change-Id: I4f7d471a601d2a683cb5a9da5e02e3fab576c26a
When a shared object is rebuilt, all dependent libraries and
executables are rebuilt. Such rebuild is unnecessary when there
is no interface change. With this patch, .toc files will be
generated for all .so files. The rule which generates .toc files
has ninja's restat=1 and .toc files are not changed ninja won't
rebuild dependent targets.
Performance:
$ m && touch bionic/libc/stdio/stdio.c && time m
Before: 1m03s (2563 targets)
After: 21s (90 targets)
Bug: 24597504
Change-Id: Ia5dd950273d143f4e99eee8bef7478f1a94cd138
LOCAL_SRC_FILES_EXCLUDE will be used to filter files out of
LOCAL_SRC_FILES. A common usage will be to use
LOCAL_SRC_FILES_EXCLUDE_<arch> to remove a source file that will be
replaced with an arch-optimized version.
Change-Id: I75cc6114c47fb784bab65cae8f618c4f395f07bb
Ninja has an implicit dependency on the command being run, and kati will
regenerate the ninja manifest if any read makefile changes, so there is no
need to have dependencies on makefiles.
This won't catch all the cases where LOCAL_ADDITIONAL_DEPENDENCIES contains
a .mk file, because a few users of LOCAL_ADDITIONAL_DEPENDENCIES don't
include base_rules.mk, but it will fix the most common ones.
Bug: 23566977
Change-Id: I66de882421376303ab7233c8ce7274548f6b2199
* commit '782b98eaa1c02d935b338f7317fef139067291bb':
Revert "Default to hiding libgcc symbols in each object."
Revert "Don't apply --exclude-libs for the host."
The Mac linker doesn't support this flag, and we don't actually need
it there anyway because we link dynamically to the system's compiler
runtime lib.
Bug: http://b/24166967
Change-Id: I62a926ed39d9fc487638e0c1a172762503dd633e
libchrome uses .mm (Objective-C++) files to bridge C++ code with
OS X Frameworks. This adds support for compiling .mm to .o by just
using the existing C++ support.
Bug: 24168923
Change-Id: Ia65357e2e2584dfffcb6796e214fe6b27635c3a6
shamu checkbuilds set USE_CLANG_PLATFORM_BUILD, which shouldn't apply to
modules built for windows. Also fix some flags that were being set
improperly.
Bug: 23566667
Change-Id: Id4c5b7cc59966328483d90f2b7be3f35e439ecee
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
So that we can support building both linux and windows binaries at the
same time on a linux host. This replaces the ifeq($(HOST_OS),...) checks
in Android.mk files.
Bug: 23566667
Change-Id: I693e11984e36d55bb6f09fa0d49bc485463e16fb
Work around gyp's inability to handle compound extensions by expecting
a similar looking simple extension for XML files definine DBus
interfaces. We'll need to rename these sources in the places we're
using them already.
Bug: 23380180
Change-Id: Ieb2050f3ef05456cd70de65c3e128d57a6a508f8
Enable daemons exposing an interface over DBus to easily
build client libraries. Now daemons can write rules like:
include $(CLEAR_VARS)
LOCAL_MODULE := libdbus-binding-example-client
LOCAL_DBUS_PROXY_PREFIX := dbus-example-example
LOCAL_SRC_FILES := \
dbus_bindings/org.chromium.Example.Manager.dbus.xml \
dbus_bindings/dbus-service-config.json
include $(BUILD_SHARED_LIBRARY)
to expose a client library.
While here, add support for generating independent adaptor header
files on a per interface basis.
Bug: 22608897
Change-Id: I011f9afc234811c31e445898321c2731c482fa77
Apparently -w will disable all warnings on GCC regardless of ordering
(clang will still respect ordering so warnings that are enabled after
-w are still respected). This is insane. Strip -w from the cflags.
Anyone that wants this flag should be turning off the specific
warnings (or just fix them), not disabling all warnings.
Change-Id: I2ba065637dfdc192921da4d9adbdc63b728c166f
This also drops the NDK default back to C++98 (or C++11 for code using
libc++). The platform NDK build should match the normal NDK build.
Bug: http://b/23043421
Change-Id: I3a336767ce271e84f4dfdebdadb3a98e5689def9
Its presence requires #include directives to contain the build target
name, which is problematic because these directives can live in headers
that are shared by multiple build targets. Furthermore, having
LOCAL_MODULE in the generated header path is redundant because the
target directory is already private to the current build target (e.g.
.../<target_name>_intermediates/...).
Bug: 22608897
Change-Id: I059f71a1231e80f89c99441794a4491f2685036f
With this patch, we can now write Android makefiles like:
include $(CLEAR_VARS)
LOCAL_MODULE := dbus-binding-example
LOCAL_SRC_FILES := main.cpp \
dbus-service-config.json \
org.example.Daemon.Command.dbus.xml \
org.example.Daemon.Manager.dbus.xml
include $(BUILD_EXECUTABLE)
This will cause header files defining native DBus interfaces
to be generated. These can be included from main.cpp to
easily expose object oriented interface over DBus.
Bug: 22608897
Change-Id: Ic4304ac8de77de74d6955ed17789e5477be9a53e
- Don't overwrite [TARGET|HOST]_[CC|CXX] with the [CC|CXX]_WRAPPER prefix,
so that we can disable the wrapper per module.
- Disable ccache on a module when FDO is enabled.
Bug: 22612634
Change-Id: Ibc04a4742d589955066c7eceb43a0da9a2b893bc
(cherry-pick from commit c671a7cf5c)
- Don't overwrite [TARGET|HOST]_[CC|CXX] with the [CC|CXX]_WRAPPER prefix,
so that we can disable the wrapper per module.
- Disable ccache on a module when FDO is enabled.
Bug: 22612634
Change-Id: Ibc04a4742d589955066c7eceb43a0da9a2b893bc
Another change in bionic/linker adds linker_asan/linker_asan64 that
know where to find ASan shared libraries.
Also, include linker_asan to the required packages list when building
for ASan.
Change-Id: I8ebe7c0091bbeb0c135708a891d33d9844373d37
Clang is really aggressive at optimizing a handful of cases (read:
clang will ruin your day some if you write bad code). Fortunately, it
also emits a warning when it's about to do this.
To prevent anyone from suffering from these optimizations, make these
warnings errors and make them impossible to disable.
Change-Id: I5e10bb0fc2ca23190017da716b3b84635577a0bd
Clang will sometimes generate this call (dex2oat with ubsan is one
known case), and it doesn't exist in libgcc.
Change-Id: I2eb68e2a326eb0407dca03b5870077eeebca1c0a
"LOCAL_FDO_SUPPORT := always" enables FDO without user specifying
"BUILD_FDO_OPTIMIZE := true", i.e. it turns on FDO for a
module in any build configuration.
Change-Id: I05d8db2edb2b3f5db073fa14d5bf1083a04571c0
(cherry picked from commit 45d0143ab1)
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
There will be two version of the the nanopb-c library,
libnanopb-c-2.8.0 which doesn't support automatic malloc
and libnanopb-c-2.8.0-enable_malloc which does.
Set LOCAL_PROTO_OPTIMIZE_TYPE=nanopb-c which doesn't support
malloc and set it to nanopb-c-enable_malloc which does.
For client code details see nanopb-api:
http://koti.kapsi.fi/jpa/nanopb/docs/reference.html
Change-Id: If238412463aabb5e1d556dfc9c464bcaf9e3333a
Previously when a file in LOCAL_SRC_FILES starts with "../", the object
file may escape out of the module's intermediate directory, because we
insert the source file's path (but not with LOCAL_PATH) to the object
file's path. Even worse when two object files escape to the same destination
and cause conflict.
This change fixes the issue by removing the "../" inside the object
files' paths. To do that, we have to set up the compilation rules for
those files one by one, instead of using the one-for-all static
pattern rules.
Bug: 19641115
Change-Id: I19f3c48ece3244fa14acb2caa609deea710840d3
- Removed unnecessary dependency of
"$(my_symlink) : $(LOCAL_INSTALLED_MODULE)"
We can generate symlink to nonexistent file.
Actually in multilib build $(LOCAL_INSTALLED_MODULE) points to file
that may not be the target file of the symlink and leads to always
obsolete $(my_symlink) in the above dependnecy.
- Touch by-product in the dummy rule, to make sure the by-product is
newer than the main-product.
Change-Id: I2f0e0cc197c49f920fa1f6794083b21cdc333c20
Note that this doesn't play nicely with acov out of the box. Clang
apparently generates .gcno files that aren't compatible with gcov-4.8.
This can be solved by installing gcc-4.6 and invoking lcov with
`--gcov-tool /usr/bin/gcov-4.6`.
http://stackoverflow.com/questions/17758126/clang-code-coverage-invalid-output
Change-Id: I79547e1c579fa79db47ff07d5e90c42cedbd5cbb
Don't remember why I didn't enable this for the host when I made the
first pass, but it works just fine.
Change-Id: I0892c0bc353bf8b60b432ba9f69f97281177d41d
So the build system regenerates import_includes when you modify
Android.mk to add a new dependency library.
Change-Id: Ic92b097b659bb68a9065e1d66da59e0dc7e2836a
The proto handling will modify the set of dependent libraries, but
this was not actually accounted for in dependency handling because
dependencies had already been established.
Change-Id: Iba1582f3c9eeeada19569e4b5358b6ec4168fccc
We had discussed the idea of making all host tools default to using
ASAN. Even if we don't make it the default, this makes it easy for the
user to switch all host binaries over.
Change-Id: I64a5c741b1b4e9aefed3a6be8dcd4f386e06b29c
Pass -fsanitize=address instead of manually specifying asan libraries
and other linker flags.
Note that we enable LOCAL_ALLOW_UNDEFINED_SYMBOLS by default for host
builds because ASAN only links symbols in the final executable, so
there will _always_ be undefined symbols in intermediate libraries.
Bug: 18208352
Change-Id: Ief55ab296e94974560eeb10507ec8d90f0025d5c
This will be necessary to support -std=gnu99 mode for clang 3.6, which
defaults to C11 mode (unlike prior releases that use C99).
Change-Id: Iea84582f9f12ba76b988463cbc0a20bd61042538
This feature is now available in AOSP, but not for any shipped
release. We don't have an API version for the release that this will
be available in yet, so for now the check is commented out.
Bug: 18395015
Change-Id: I247233d047ed5a7564d6602d47c9ad962313c8dc
The previous position of libgcc.a/libatomic.a on the link line causes
the linker to prefer satisfying dependencies from these libraries from
other libraries that might include them, rather than from libgcc.a (or
libatomic.a) itself. This imposes an ABI requirement that those
intermediate shared libraries _always_ export those symbols, which is
undesirable.
Change-Id: Ib593236b475d3e98356b2b1be6f96cee2b67378f
This should obviate much of the need for cleanspecs, and also make it
unnecessary to continue adding LOCAL_ADDITIONAL_DEPENDENCIES for this
sort of thing all over the tree.
Change-Id: I97aa8fd280ae868a5f6364f8b7bf3c2fe235d6ce
The NDK protobuf library depends on the final target linking stlport
(since it is a static library). Since the platform stlport is going
away, we need to use a separate version of the protobuf library that
is compiled for the platform against libc++.
Note that this should be the case for _all_ libraries built with the
NDK. If a library needs to be used by both an NDK built final target
and a platform built final target, there should be both an NDK and
platform version of the library.
Bug: 15193147
Change-Id: I0ead61c2d1cd9d0248b304ab7d8682dedd6e8366
"LOCAL_FDO_SUPPORT := always" enables FDO without user specifying
"BUILD_FDO_OPTIMIZE := true", i.e. it turns on FDO for a
module in any build configuration.
Change-Id: I05d8db2edb2b3f5db073fa14d5bf1083a04571c0
Only sort the list of shared libraries used for naming dependencies,
not the order they are actually linked in. The order in which shared
libraries appear to the linker affects which symbols get used if there
is a multiply defined symbol.
Also link system shared libraries _after_ user provided libraries,
since a user will want their functions to override the system's if
they exist.
Change-Id: I071059d940d40a648d69d90e0699073ef520138a
If a module is explicitly depending on a versioned protolib, we strip
the dependency and log a warning so the unneeded dependency can be
removed.
Change-Id: I949d32fb5126f1c05e2a6ed48f6636a4a9b15a48
Because LOCAL_CXX_STL modifies a module's required shared libaries,
we need this for also prebuilt shared libraries and executables.
Change-Id: I418c26143999a613c40aadf990f131b123e0ac3d
my_compiler_dependencies was never assigned to, but the way it was
included in the rules prevented the user from being able to use | in
LOCAL_ADDITIONAL_DEPENDENCIES. Since it is unneeded, just remove it.
Change-Id: I74bb59e81b97756296060eea5b7a42909be50130
These aren't needed now that we only use the compiler/headers that exist in
the prebuilts/clang directory.
Change-Id: I9978efb10815e92577d45629db324e0a5094f880
To enable building with coverage, the environment variable
NATIVE_COVERAGE must be set to true.
Set `LOCAL_NATIVE_COVERAGE := true` to generate coverage information for
a given component.
This is currently not supported for clang (b/17574078, b/17583330).
If static library A is included in a binary B (dynamic or static
executable, or shared library), and A is built with coverage
information, B is required to link with libgcov.a. Since the make does
not offer a good way to track this dependency, link libgcov.a even if
LOCAL_NATIVE_COVERAGE is not set (but still guarded by NATIVE_COVERAGE).
This ensures that all of the libgcov dependencies will always be
resolved, and causes no change in the resulting binary if coverage is
not used.
Bug: 10134489
Change-Id: Id5a19f2c215e4be80e6eae27ecc19b582f2f6813
Preparing for migration from stlport to libc++. STL selection is done
with LOCAL_CXX_STL (valid values are default, none, libc++,
libc++_static, stlport, stlport_static, bionic).
The selection of the STL is as follows:
if LOCAL_CXX_STL == 'default'
ifdef LOCAL_SDK_VERSION
Use whatever STL the other NDK options have selected.
else
Use bionic's libstdc++ for target, GNU libstdc++ for host. This
is compatible with the existing build options.
endif
else
if LOCAL_CXX_STL == 'stlport'
Use stlport.
else if LOCAL_CXX_STL == 'libc++'
Use libc++.
else if LOCAL_CXX_STL == ''
Don't use any STL.
endif
endif
Bug: 15193147
Change-Id: If712ba0ae7908d8147a69e29da5c453a183d6540
There were a few cases that my_clang was being used without being
stripped. This was causing uses like the following to fail because it
would be partially applied (use clang as the compiler, but don't strip
out incompatible cflags).
LOCAL_CLANG := true # explanation
To avoid this problem in the future, just strip my_clang when it is
assigned.
Change-Id: I41c2f36a4d4c3aa305a25b4a151c066dad5ffe0f
* commit '5b81106eb5c5c9a616874caae5ea91b45a45e9d6':
Explicitly check if LOCAL_FDO_SUPPORT is true (instead of empty). Change-Id: Icff260c7f866236254091b035782607a31e5a109
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
(cherry picked from commit 4803ce2696)
We've been using -fPIC and -fPIE together in the global cflags all this
time. These options are incompatible. The only reason we haven't been
hit by this before is because of the forced -Bsymbolic in GCC. To fix
this, pass -fpic when compiling objects for shared libraries and -fpie
when compiling objects for executables. For static libraries, also use
-fpic. We have to do this because static libraries might be included in
either a shared library or an executable. Code compiled with -fpie
cannot be included in a shared library, but code compiled with -fpic
may be included in an executable.
We've also been using -fpic and -fPIC together. These are different
options, and only the latter will take effect.
http://stackoverflow.com/a/967010
The final thing this fixes is that we had -f(PIC|PIE) flags being passed
to link commands. These are compile time flags, and don't do anything at
link time.
Bug: 16823325
Change-Id: Ic76f47e63dc2c81b7e1a8058bae1b3dc8565d606
If LOCAL_CLANG is not set to false for a host module, clang will be used instead of gcc.
This also enables the integrated assembler by default for Darwin host builds.
bug 16172793
Change-Id: If7484c5dbcccce7d925bec97bff0a3e4c30e9434
Previously we only expanded product_MODULES with LOCAL_REQUIRED_MODULES,
but not modules introduced by LOCAL_SHARED_LIBRARIES; Later we did a further
shared libary expansion in vendor_module_check.mk.
It couldn't track C in the following case:
A : B, by LOCAL_SHARED_LIBRARIES; B : C, by LOCAL_REQUIRED_MODULES.
With this change, we transformed the LOCAL_SHARED_LIBRARIES dependencies
into LOCAL_REQUIRED_MODULES dependencies before doing the required
module expansion and the loophole is closed.
All module names are now expanded to product_MODULES now and it makes
vendor_module_check.mk simpler.
Change-Id: I8835a478d2ce0ce10601a8449f446f07b01c2b7f
Previously the RS cpp files are generated by the timestamp rule. Though
we have the generated RS cpp files depend on the timestamp file, we
don't have a build recipe. In such case gmake does some "optimization"
that it skip recompiling the generated cpp files, because it assumes the
generated cpp files are already up to date even if the rs files have
been updated.
Bug: 15313144
Change-Id: Ie69ecd2c788057d3619f9c7d2a125d44c4a534a1
This fixed issue that gnumake skip updating the cpp file that includes
the generated header file when the .proto file gets updated.
For example:
Say a.cc includes b.pb.h, since b.pb.h is just byproduct of the rule
that generates b.pb.cc, and though we have dependency "b.pb.h :
b.pb.cc", but we don't have build recipe for that rule.
Gmake stupidly thinks that b.pb.h must not be updated in that case so
it skips all targets that depends on b.pb.h!
With the dumy build recipe, gmake now doesn't skip the depedent targets.
Bug: 13009798
Change-Id: I39adc09b7656bdd023f578fb8933667944fd974c
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
- Automatically export the include path of the generated .pb.h files
- Set up the dependency to make sure the .pb.h files get generated
before any dependent c/c++ files get compiled.
With this change, any module that links a proto library doesn't need
any extra setup.
Bug: 14563418
Change-Id: Iea7d19e9d8dce8e7d479c386b7a6151a95a0a0df
prebuilts/ndk/current/platforms/android-19/arch-x86_64/usr/lib
is renamed to usr/lib64 to be more consistent with rest of
lib paths in x86_64 toolchain, which is multilib
See https://android-review.googlesource.com/#/c/92441/
Change-Id: I4e59245505d0fa87ae3608e81e715ccfcecc5ec8
Change runtime library name to keep in sync with upstream.
Enable frame pointers in instrumented code for fast stack unwind.
Change-Id: I815912bb856c56c399639ea76ad4cb6b97961840
* commit '8295d6cd62ba73ea66e64204d2d0ea27b4b34889':
add support for LOCAL_MODULE_STEM_32 and LOCAL_MODULE_STEM_64
add support for LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64
Some executables will need to be built for both 32-bit and 64-bit.
For tests, it will be convienient to keep the name of the executable
the same, but install them in a different location. Add
LOCAL_MODULE_PATH_32 and LOCAL_MODULE_PATH_64 to allow a module
to specify different paths for 32-bit and 64-bit executables.
Change-Id: I3be830e899c6d485fe55c25c66b20b3fe64c795e
Previously we have only one set of include/lib paths for
LOCAL_NDK_STL_VARIANT:=gnustl_static regardless of GCC
version, which is wrong because each GCC version
come with its own libstdc++.
Change-Id: I2a01c2120b6948aedce00e2f8d08dfc6932126dd
Previously the installed shared library dependency doesn't include
modules introduced by LOCAL_SHARED_LIBRARIES_<arch>.
This change fix the problem.
It also cleans up use of the shared library variable.
Bug: 13528787
Change-Id: Id8d807cc57f0ec4a71f18b64545d91191efad8fb
Dan Albert