There is a much better way to do this. I have outlined it in a prior post, but I don't have time to dig it out or recreate it tonight.
I'm planning to turn it into a blog post at some point. Basically, you do not need conditional compilation. The *only* Java code which needs to change is the generated R.java file -- and even that you should be able to generate correctly, though I wasn't able to get it to work. It can all be done with an ant script. The manifest needs to be processed. It's helpful to process some resource files -- for example, to embed the version number, etc. XSLT is your friend here, it's much easier to manipulate XML than to deal with all the issues with preprocessing -- including completely screwing up line numbers, in most cases, but commenting out rather than omitting lines should avoid that! To avoid screwing up the debug cycle, I produce by default a dev version, which gives access to both free and pro functionality for test and debug. It works really well, but there's a few quirks I wish I had time to explain just now; I hope I covered them in my earlier message, which I hope you can find... Feel free to bug me more on the topic after April 1. On Mar 30, 5:45 pm, John Seghers <jsegh...@cequint.com> wrote: > In the J2ME world of wildly non-conforming implementations, > conditional compilation is the norm. Sun even admited it by adding > "configurations" (IIRC) to NetBeans 5. EclipseMe (Now the official > Eclipse Mobile Tools for Java project--MTJ) has support for it, as > does the Antenna extension to Ant. > > The most common method currently is to use a construction such as > //#if CONDITIONAL > ... > //#endif > This shields the conditional statement from language-aware but > conditional-unaware editors. The build system then comments out the > intervening lines of code if the condition is not met. I've used > everything from ant processing to running the full Java code (and even > XML files) through the C++ preprocessor for macro expansion. > > In Android, especially when trying to maintain two versions of a > product (Free vs. Paid, for example) conditional compilation (or > parallel code trees) is mandatory because the package names must > change (at least in the manifest). This is one case where the if > (const) blocks will not work. If there is a better way of handling > this, please enlighten us. > > I haven't yet tackled this problem in the Android dev environment > because it tends to disrupt the debug part of the edit-compile-debug- > edit cycle. What I have done is to add an eclipse builder to run a > perl script to generate a Java interface (in the gen/ directory) that > defines constants for build time/number pulled from Team Foundation > Server. This allows automatic version stamping for the about screen-- > though does not yet modify the version name/number in the manifest. > > On Mar 30, 9:42 am, Bob Kerns <r...@acm.org> wrote: > > > > > You can download a Java decompiler and investigate yourself. I suggest > > this one:http://java.decompiler.free.fr/?q=jdgui > > > You'll see that it does indeed optimize when it can. > > > However, unlike a C file which gets linked into a .so or .dll or an > > executable, Java classes may be combined in different ways. > > > So it cannot optimize away static final references in other classes, > > because those may change. > > > However, tools like ProGuard can do so, because they work on an entire > > application. > > > But remember, once you do something like this, that code can never be > > used in a context with a different valiue. > > > It virtually never makes sense to do this for conditional compilation > > reasons. Sometimes it makes sense to generate code (the Android tools > > do in fact generate a couple of files). In the rare case you do need > > to eliminate code due to extremely tight performance constraints or > > size constraints, I'd recommend the ProGuard route, as it will do a > > FAR more thorough job than you can do manually with conditional > > compilation. > > > On Mar 30, 8:12 am, "Kevin S." <dada...@gmail.com> wrote: > > > > It really isn't very easy to do this. In general, you can do > > > something like > > > > public class MyClass > > > { > > > public static final boolean HAS_CHEEZBURGER=true; > > > > public void someMethod() > > > { > > > if( MyClass.HAS_CHEEZBURGER) > > > { > > > doCheezburger(); > > > } else > > > { > > > noCheezBurger(); > > > } > > > } > > > > } > > > > The compiler I think will see that HAS_CHEEZBURGER is constant and > > > can never change, and may optimize away the branch not taken. Perhaps > > > some more knowledgeable folk could comment on that. > > > > If on the otherhand, you really really think you need to do > > > preprocessing using eclipse and Java, you can. See the following > > > link. > > > >http://www.boldinventions.com/index.php?option=com_content&view=artic... > > > > -Kevin > > > > On Mar 30, 5:57 am, Dilip Dilip <dileep2m...@gmail.com> wrote: > > > > > Hi All, > > > > How to do conditional compilation in JAVA. > > > > > something like in C, C++ : > > > > > #ifdef TRUE_CONDITION > > > > > #else > > > > > #endif > > > > > Thanks and Regards, > > > > Dileep- Hide quoted text - > > > - Show quoted text - -- 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 To unsubscribe, reply using "remove me" as the subject.
