Yes, one of the things we do too is clean before build. Early on we had crazy problems if we didn't. javac is so fast (compared to dx) that it really doesn't matter.
It is not enough to just pull in custom targets though (for us, anyway), as execution of those targets must occur at "good" times in the android_rules.xml target dependency chain. On Thu, Dec 10, 2009 at 12:13 PM, Jason Proctor < jason.android.li...@gmail.com> wrote: > i'm down the no-Eclipse road too, largely because it sucks :-) > > i routinely add "clean" and "libext" targets to Android build.xml > files, to pull external libraries and to ensure old build products > are removed before generating new ones <= i don't know how, but > sometimes old stuff is left lying around in R.java or wherever and > can severely confuse matters. IMHO, the standard build.xml should > clean before building. > > yeah it would be great if the standard build.xml checked for the > existence of a custom rules/targets file and included it, so i didn't > have to add these things each time and also not have them blown away > when the android tool rewrites them etc. > > > > >We continue down our road of not using Eclipse and a customized > >build.xml file. This is because we pull sources from several trees, > >and also (a la J2ME) modify some of the source files before we > >compile them. We also make different modifications depending on > >whether it is a debug or release build. > > > >The procedure outlined below, and also described in the "android" > >command generated build.xml file, works well as far as it goes. > >Having just brought us into 2.01 compliance I thought I'd offer some > >suggestions: > > > >1. If the rules file called some do-nothing "hook" targets in the > >command-line "android" generated build.xml, we could do our mods in > >those hooks without ever touching or copy/pasting the "sacred" > >android_rules.xml. For example: "-start-debug-build-hook," > >"-start-release-build-hook," "-start-compile-hook," etc. Note we do > >need to know the difference between a release and debug build through > >the whole build process (and not just at signing time). > > > >With hook routines, android_rules could be revised and maintained > >while lowering or eliminating the impact on changes to build.xml. I > >would think the performance hit on modern machines is irrelevant. > > > >This is sort of like "custom build steps" in (ducking) Visual Studio. > > > >2. Adding an "rinstall" target to install release builds would be useful. > > > >3. Making an effort to keep the property names the same in > >build.xml/build.properties from release to release would be useful. > >(It seems like a convention for this has been chosen now, so maybe > >this is moot.) > > > >-- Ward > > > > > >At 12:29 PM -0700 4/14/09, Xavier Ducrohet wrote: > >>Hello, > >> > >>The new SDK include multiple versions of the Android platforms. > >>Because newer versions could have slightly different build steps, we > >>have decide to keep most of the build logic inside the platforms > >>themselves. > >> > >>Thus, the new build.xml imports a file called android_rules.xml > >>located inside SDK/platforms/<platform>/templates/ (it might move in > >>the final SDK but you shouldn't care much). > >> > >>This file actually being imported is resolve in the first step of the > >>build. The custom task <setup /> looks at the value loaded from > >>"default.properties" which contains the target project (ie which > >>platform/add-on the project is compiling for), and then import the > >>proper rules file (after doing some properties init as well). > >> > >>If you want to change the rules to make them your own, I'd sugges to > >>leave android_rules.xml unchanged, and instead copy the rules inside > >>your build.xml file, *after* the <setup /> task. > >>Additionally, change the setup task to <setup import="false"/>. This > >>will let the custom task do the properties init but not do the import. > >> > >>Some of the target in the rules files are slightly different than > >>before, with some using custom tasks as well. This is due to a new > >>feature to generate multiple APKs from a single project (with > >>different resources). > >>You can either ignore this and reuse some of the previous target/task, > >>or modify the custom task to do what you want (we're pushing the > >>source used to generate this SDK on the git server today) > >> > >>Xav > >> > >>On Tue, Apr 14, 2009 at 9:50 AM, Ward Willats <goo...@wardco.com> wrote: > >>> > >>> 'Round these parts we don't use Eclipse and heavily customize our > >>> build.xml file. The "android" tool tried to update it and burped out > > >> a short, confused file. > >>> > >>> That's OK. Don't mind doing build.xml by hand and "target-ifying" it, > >>> but I see what look like a whole set of Android-specific ANT > >>> tasks/libs (prefs, apkbuilder, jarutil..), of which only <setup> went > >>> into the new build.xml. > >>> > >>> So.....do I have to include any other custom ANT tasks besides > >>> <setup>? Or can I just use more-or-less the same command lines as > >>> before with aapt, javac, dx, etc...? > >>> > >>> And what are these "rules" setup uses? And where are they included > from? > >>> > >>> Thanks > >>> > >>> -- Ward > >>> > >>> > > >>> > >> > >> > >> > >>-- > >>Xavier Ducrohet > >>Android Engineer, Google. > >> > >>--~--~---------~--~----~------------~-------~--~----~ > >>You received this message because you are subscribed to the Google > >>Groups "Android Developers" group. > >>To post to this group, send email to android-developers@googlegroups.com > >>To unsubscribe from this group, send email to > >>android-developers-unsubscr...@googlegroups.com > >>For more options, visit this group at > >>http://groups.google.com/group/android-developers?hl=en > >>-~----------~----~----~----~------~----~------~--~--- > > > >-- > >You received this message because you are subscribed to the Google > >Groups "Android Developers" group. > >To post to this group, send email to android-developers@googlegroups.com > >To unsubscribe from this group, send email to > >android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > >For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > > -- > jason.vp.engineering.particle > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
