Closed Bug 727960 Opened 13 years ago Closed 13 years ago

Incremental builds for mobile are too slow

Categories

(Firefox Build System :: General, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla13

People

(Reporter: BenWa, Assigned: glandium)

References

Details

Attachments

(2 files)

I managed to get incremental cpp builds to <20 seconds by doing the following: Patch APKOpen.cpp: - xul_handle = __wrap_dlopen("libxul.so", RTLD_GLOBAL | RTLD_LAZY); + xul_handle = __wrap_dlopen("/data/libxul.so", RTLD_GLOBAL | RTLD_LAZY); (Do a full rebuild) Once that is done you can modify a cpp file, rebuild using the objdir method, relink, copy and strip libxul.so and adb push to /data/libxul.so: incremental_build.sh gfx (Does objdir build on gfx + relink) cp ../builds/obj-fennec/toolkit/library/libxul.so . && /home/bgirard/mozilla/android/android-ndk-r5c/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-strip libxul.so adb push libxul.so /data/libxul.so With gold installed this makes the turn around time very fast. Can we get this patched in properly with a supported way to trigger it?
Specifically what I was suggesting was a way to disable our internal linker, so that he could just rebuild libxul and push it to the device.
I don't fully understand our linker/elfhack magic that happens on the device but being able to push libxul.so to the device is exactly what I need.
Would it work for you if make package was simply faster? IIRC, mounir filed a bug for that.
If we can get the package step down to 1-2 seconds it would be better then this, otherwise this method makes the package step not needed thus free. When rebuilds are in the 20 second range each second is very valuable.
(In reply to Benoit Girard (:BenWa) from comment #0) > I managed to get incremental cpp builds to <20 seconds by doing the > following: > > Patch APKOpen.cpp: > - xul_handle = __wrap_dlopen("libxul.so", RTLD_GLOBAL | RTLD_LAZY); > + xul_handle = __wrap_dlopen("/data/libxul.so", RTLD_GLOBAL | RTLD_LAZY); > > (Do a full rebuild) > > Once that is done you can modify a cpp file, rebuild using the objdir > method, relink, copy and strip libxul.so and adb push to /data/libxul.so: Note that starting fennec with the debug intent (see how on the wiki), the library is extracted to and loaded from /data/data/org.mozilla.fennec_$user/cache. With the new linker, it's overwritten each time you start, but with the old linker (export MOZ_OLD_LINKER=1 in mozconfig), it's not if the file in the cache directory is newer than the apk. So currently, if you build with MOZ_OLD_LINKER=1 and start with the debug intent, you should be able to adb push libxul.so /data/data/org.mozilla.fennec_$user/cache and have the same behaviour as the one you want. You can also change the cache directory if you change the MOZ_LINKER_CACHE environment variable, which is set in the java code. So if making make package fast is not good enough for you, we could: - make the new linker do the same as the old linker wrt timestamps - make it easier to override MOZ_LINKER_CACHE (iirc you need root to write in /data/data/org.mozilla.fennec_$user/cache)
That would be wonderful, something simple we can roll into a script.
This also does some cleanup in the code.
Attachment #599066 - Flags: review?(taras.mozilla)
(In reply to Mike Hommey [:glandium] from comment #5) > So if making make package fast is not good enough for you, we could: > - make the new linker do the same as the old linker wrt timestamps The patch I attached implements this. > - make it easier to override MOZ_LINKER_CACHE (iirc you need root to write > in /data/data/org.mozilla.fennec_$user/cache) I'll leave that to people who know Android APIs. This could also be done in a separate bug, whatever suits you best. Maybe the patch here is enough for you, Benoit ?
So if I understand correctly I can set MOZ_LINKER_CACHE=/sdcard/data and push an updated+striped libxul.so there?
(In reply to Benoit Girard (:BenWa) from comment #9) > So if I understand correctly I can set MOZ_LINKER_CACHE=/sdcard/data and > push an updated+striped libxul.so there? Java code is going to override MOZ_LINKER_CACHE, so not directly (which is why there is the second point). But you can push a libxul.so in /data/data/org.mozilla.fennec_$USER/cache, as long as you start with the debug intent (am start -a org.mozilla.gecko.DEBUG ...)
Attachment #599066 - Flags: review?(taras.mozilla) → review+
Whiteboard: [leave open after inbound merge]
With this patch, starting with: am start -a org.mozilla.gecko.DEBUG -n org.mozilla.fennec_mh/.App --es env0 MOZ_LINKER_CACHE=/data/local/tmp does what Benoit wants. Note that using /sdcard wouldn't work because you can't map executables from there.
Attachment #599579 - Flags: review?(mark.finkle)
Attachment #599579 - Flags: review?(mark.finkle) → review+
Whiteboard: [leave open after inbound merge]
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
Blocks: 732117
No longer blocks: 732117
I made some time to try it out now that the debug intent got fix with no luck :( cp ../builds/obj-fennec/toolkit/library/libxul.so /tmp/libxul.so && arm-eabi-strip /tmp/libxul.so && adb push /tmp/libxul.so /data/local/tmp/libxul.so shell@android:/ $ ls -l /data/local/tmp -rwxrwxrwx shell shell 358026 2012-01-19 12:41 gdbserver -rwxrwxrwx shell shell 18595804 2012-04-17 15:02 libxul.so adb shell am start -a org.mozilla.gecko.DEBUG -n org.mozilla.fennec_bgirard/.App --es env0 MOZ_LINKER_CACHE=/data/local/tmp
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Since then, the debug intent doesn't trigger extraction. So you need to add another variable: MOZ_LINKER_EXTRACT=1 (with --es env1)
It works now. However having to launch fennec from command line is a big pain. Accidentally starting the program from the icon will get the old configuration so it's prone to errors :(.
Status: REOPENED → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: