This is more efficient as find itself can handle correctly passing
arguments down to the command, and this is in POSIX. The current
versions of OS X also support this form.
BUG=None
TEST=mgrep still works
Change-Id: Ie570867609113868daaf068658c4f7e6f4ae42fa
When a directory isn't present with mmm, don't show "No Android.mk present", rather show that the directory isn't present
Change-Id: I7259a60012c6f30c470daa60d5a5097d01ffc4c7
Signed-off-by: Abhinav1997 <abhinav.jhanwar.august2@gmail.com>
This will run ${ANDROID_PRODUCT_OUT}/provision-device which in turn can
run fastboot (and other vendor-specific bits, if needed) to repartition
the device and reflash all partitions with known versions. Options
passed to the 'provision' command will be passed on to said script which
is expected to pass them on to fastboot.
Since this is a rather destructive operation involving data loss etc.,
user confirmation is required. This confirmation can be bypassed using
the option --no-confirmation.
Change-Id: Iec5667f2f5070b95d2eb70ad1b2984909ae4184c
This avoids Ninja's path canonicalization on those goal names.
Without this, Ninja complains about duplicate rules for
MODULES-IN/a/b/.. and MODULES-IN/a.
Bug: 24309760
Change-Id: Id3aa9da5d3887a2cd1426cbb5fdf35659c65805e
Previously we use command line variable BUILD_MODULES_IN_PATHS which
causes kati to regenerate build.ninja if any variable value changes.
TODO: Remove the old rules of BUILD_MODULES_IN_PATHS in
build/core/main.mk and ninja.mk once users have re-sourced envsetup.sh.
Probably in a few weeks.
Caveat: With this change, if a user sources the new envsetup.sh, mma/mmma
won't work in old branches from the same shell.
Bug: 24309760
Change-Id: I212e82aeebaaa2bd4114e2066f1995da8886b5e2
Nothing else was being imported from system/core yet, and a path under
development makes more sense for this.
Bug: http://b/22881740
Change-Id: Ib0beb02137805b3e382535514a2bc067b7fd1d33
We used to rely on envsetup.sh to set up PATH before doing kernel build.
Now we have new kernel build process.
Also the variable doesn't work any more as we don't have corresponding arm-eabi
toolchain for the latest arm-linux-androideabi toolchain.
Change-Id: I99443fdc58e94f57f4f1f7e88da6dd127f3b2fac
There's an adb Python interface now, and system/core needs to be in
the PYTHONPATH for `import adb` to find it.
Change-Id: I712767a2ba96cb017ce5857dc367e4cacf2ec51f
For historical reason, the aosp_* products were named full_*.
We keep the full, full_x86 and full_mips in case some tools still
reference these legacy names; But no reason the have the full_* product
names for the new 64-bit archs.
Change-Id: I240ed0c6ded0ded2d80603bd0c5ff24750999afc
Blocking these sequences on Darwin has false positives (Terminal.app)
and false negatives (Eclipse CDT on Linux). Instead let's ask the
terminal what it supports.
Change-Id: I907942925a8b30abc1ea920f077b5fc3af815ba4
Signed-off-by: Greg Hackmann <ghackmann@google.com>
gdbclient looks for 'x86_64-linux-androideabi-gdb' whereas the prebuilts
have gdb as 'x86_64-linux-android-gdb'
$ cd $ANDROID_BUILD_TOP
$ find prebuilts -iname *x86*gdb
prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/bin/x86_64-linux-android-gdb
prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.8/bin/x86_64-linux-android-gdb
prebuilts/gcc/darwin-x86/x86/x86_64-linux-android-4.9/bin/x86_64-linux-android-gdb
prebuilts/gcc/darwin-x86/x86/x86_64-linux-android-4.8/bin/x86_64-linux-android-gdb
Change-Id: Ib940ecd6f345ea501da79834168b91cc0f6e5a96
