This relands I12a0f907753fefd1997ab8b4ea2ac331234093cf along with
a fix to blueprint for absolute paths.
Store the current working directory and then change to the root
directory so that all file accesses must go through helpers in
the android package that properly track dependencies.
Change-Id: I24ac485677aa102eec1a2521d16820da6ee1ae77
Fixes: 146437378
Test: m checkbuild
Test: m OUT_DIR=/tmp/out nothing
Store the current working directory and then change to the root
directory so that all file accesses must go through helpers in
the android package that properly track dependencies.
Fixes: 146437378
Test: m checkbuild
Change-Id: I12a0f907753fefd1997ab8b4ea2ac331234093cf
Native compiler flags are currently applied in approximately:
global cflags
local cflags
local include dirs
global include dirs
global conlyflags
local conlyflags
global cppflags
local cppflags
This means that a flag that is enabled in the global cppflags
cannot be disabled in the local cflags, and an Android.bp author
must know to disable it in the local cppflags. A better order
would be:
global cflags
global conlyflags
global cppflags
local cflags
local conlyflags
local cppflags
local include dirs
global include dirs
We are mixing both the global and local cflags into a single
variable, and similar for conlyflags and cppflags, which
prevents reordering them. This CL prepares to reorder them
by splitting the global and local cflags into separate variables.
Bug: 143713277
Test: m native
Change-Id: Ic55a8c3516c331dc5f2af9d00e59ceca9d3e6c15
Problem: Soong does not guarantee that the list of parameters will
be in individual strings. This means the CMakeLists generator can
receive as input:
params = {"-isystem", "path/to/system"}
or it could receive:
params = {"-isystem path/to/system"}
Solution: Normalize the list of parameters into a flattened list
of parameters where each parameters is in an individual string.
Fixes: 143378093
Test: None
Change-Id: I9bd1a2006a1cf0ba383f467748b6fd4eadef6866
Clang is always used now, so we can remove all the GCC checks. Removing
GCC-specific configuration will happen in the next CL.
Test: m
Change-Id: I4835ecf6062159315d0dfb07b098e60bff033a8a
* Add relativeFilePathFlag compiler flag category whose format must be
a=b/c/d, where "a" is the flag name and "b/c/d" is the flag value that
is a relative path
* During CMake conversion, "b/c/d" will be prefixed with ANDROID_ROOT
before being written to CMakeLists.txt
Bug: 112599284
Test: cd system/bt; mm -j40
croot; make -j40
Change-Id: I4bb039678482201db60f0af97ab280d5028e0463
Modules may have multiple variants for each architecture, and
SOONG_GEN_CMAKEFILES=1 was generating CMakeLists.txt for all of
them, overwriting the first normal variant with the last (and
likely least normal) variant.
Keep a map of generated CMakeLists.txt files, and only generate
each one once.
Bug: 72283227
Test: m SOONG_GEN_CMAKEFILES=1
Change-Id: If31087264d2809088fe36965b9a0ff0f44089852
In Soong, a Config() method will always return a Config. Make
ModuleContext, SingletonContext, TopDownMutatorContext and
BottomUpMutatorContext's Config() methods explictly return
a Config to avoid having to type-assert everywhere. Overriding
the Config method requires duplicating the list of methods in
blueprint.BaseModuleContext and blueprint.BottomUpMutatorContext,
following the same pattern used by the other *Contexts.
Config() obsoletes the AConfig() method used in some places, which
will be cleaned up in the next patch.
Test: m checkbuild
Change-Id: Ibe21efde933959811d52443496967ab8ce71215e
Wrap blueprint.PackageContext so that the *Func methods can provide
an android.Config instead of an interface{}. The modified signatures
means that every method in ModuleContext and SingletonContext
that takes a blueprint.PackageContext now needs to be wrapped to
take an android.PackageContext.
SingletonContext wasn't previously wrapped at all, but as long
as it is, wrap everything like ModuleContext does. This requires
updating every Singleton to use the android-specific methods.
Test: builds, all Soong tests pass
Change-Id: I4f22085ebca7def6c5cde49e8210b59d994ba625
Include order should be module includes, dependency exported includes,
and then global includes. Module includes and global includes are
computed during compileFlags, but dependency exported includes are
not handled until later. Move the global includes into a new
flags variable so that the dependency includes can be appended
to the module includes.
Test: m -j native
Change-Id: Ifc3894f0a898a070d6da8eed4f4b9e8cc0cd2523
Refactor doesn't work in CLion unless we also add the headers in
the header search path to the list of source file in a project.
Change-Id: Idc6223149ecf7ddf0c21bc0873ad3019ec6ccdd3
Treble genererated project name feature character no accepted by
CMake. So far only @ is a problem.
Change-Id: Iac460033f1181f46ab8205e5706271f99ab798d3
For some library, the order of includes is important. e.g: library
can include "system/window.h". Dependending on the dependency order
this could mean libs/nativewindow/include/system/window.h or
system/core/include/system/window.h
This patch changes search path storage from map to array in order
to preserve order the order in which they were received from
soong.
Change-Id: I8ef788633985f4ed04ec3432686eb1427f73d600
Test: Manual
Colin Cross