New build system always re-scan makefiles?

[Chih-Wei Huang]

Try to build Android 7.0, the new build system is much faster.
Looks great! However, I noticed it always
re-scan all Android.mk since it detects something
is changed. Actually it's not.
I just do another make after the previous successful make.
I expect it should show "Nothing to be done".

How to avoid that?

$ make -j32
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=7.0
TARGET_PRODUCT=android_x86_64
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=x86_64
TARGET_ARCH_VARIANT=x86_64
TARGET_CPU_VARIANT=
TARGET_2ND_ARCH=x86
TARGET_2ND_ARCH_VARIANT=x86
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.13.0-40-generic-x86_64-with-Ubuntu-14.04-trusty
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=NRD90M
OUT_DIR=out
============================================
make: Entering directory `/home/cwhuang/git/android-x86-7.0'
Running kati to generate build-android_x86_64.ninja...
$(shell cd bootable/recovery/tests ; find -L  testdata/*) was changed, regenerating...
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ WHAT? I didn't change that
 
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=7.0
TARGET_PRODUCT=android_x86_64
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=x86_64
TARGET_ARCH_VARIANT=x86_64
TARGET_CPU_VARIANT=
TARGET_2ND_ARCH=x86
TARGET_2ND_ARCH_VARIANT=x86
TARGET_2ND_CPU_VARIANT=
HOST_ARCH=x86_64
HOST_2ND_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.13.0-40-generic-x86_64-with-Ubuntu-14.04-trusty
HOST_CROSS_OS=windows
HOST_CROSS_ARCH=x86
HOST_CROSS_2ND_ARCH=x86_64
HOST_BUILD_TYPE=release
BUILD_ID=NRD90M
OUT_DIR=out
============================================
including ./abi/cpp/Android.mk ...
including ./art/Android.mk ...
including ./bionic/Android.mk ...
including ./bootable/newinstaller/Android.mk ...
including ./bootable/recovery/Android.mk ...
including ./build/libs/host/Android.mk ...
including ./build/target/board/Android.mk ...
including ./build/target/product/security/Android.mk ...
...

[Dan Willemsen]

If you run:

$ (cd bootable/recovery/tests ; find -L  testdata/*)

multiple times, does it give you the results in different orders? Does it return different results before and after a build?

find does return results in filesystem order, which is not defined. This hasn't been a problem with any filesystem that I've seen -- you always get the same order until something changes in that directory, then the order may change.

- Dan

--
--
You received this message because you are subscribed to the "Android Building" mailing list.
To post to this group, send email to android-...@googlegroups.com
To unsubscribe from this group, send email to
android-buildi...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-building?hl=en

---
You received this message because you are subscribed to the Google Groups "Android Building" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-buildi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Chih-Wei Huang]

Dan Willemsen於 2016年8月27日星期六 UTC+8上午12時51分26秒寫道：

If you run:

$ (cd bootable/recovery/tests ; find -L  testdata/*)

multiple times, does it give you the results in different orders? Does it return different results before and after a build?

It always gives the same results.
If not, I'm surprised since nobody change
any file in bootable/recovery/tests.

find does return results in filesystem order, which is not defined. This hasn't been a problem with any filesystem that I've seen -- you always get the same order until something changes in that directory, then the order may change.

There is nothing changed in that directory.
In fact I didn't change anything under
the bootable/recovery/ dir. It's exactly
the same as AOSP.

Am I the only one see this issue?

Actually the problem is not at bootable/recovery/tests.
The problem is the new build system always thinks
something is changed. If I removed this line in
bootable/recovery/tests/Android.mk

testdata_files := $(call find-subdir-files, testdata/*)

and make again, it said
bootable/recovery/tests/Android.mk was modified, regenerating...

This is OK since I did change the makefile.
However make again it said:

$(shell cd libcore && ls -d */src/test/{java,resources} 2> /dev/null) was changed, regenerating...

(what? I didn't change libcore)