Saturday, December 11, 2010

Re: [android-developers] Re: dex in ant with external libs in SDK tools R8

we have a change in already to have our custom task check the version
of Ant. It'll be in the next release.

The issue with this particular change is that we rely on a change in
behavior from 1.7 to 1.8, not on a new task or attribute that would
fail on 1.7 :(

On Fri, Dec 10, 2010 at 2:25 PM, Andreas <andreas.rossbacher@gmail.com> wrote:
> Ok, I can confirm the bug is not happening with the latest ant
> version. My bad.
> However if using the wrong ant version is creating such strange
> mistakes you might
> consider making it mandatory or at least print a big fat warning.
> --
> Andreas
>
> On Dec 10, 12:01 pm, Xavier Ducrohet <x...@android.com> wrote:
>> hmm if you use the proper version of Ant this should not be required.
>> I double checked it a few days ago.
>> you do need Ant 1.8
>>
>> On Fri, Dec 10, 2010 at 11:52 AM, Matt Quigley
>>
>>
>>
>> <matthew.quig...@gmail.com> wrote:
>> >> Andreas,
>> >> I'm not sure where you added that line <path refid="jar.libs.ref" />.
>> >> I need to make this fix in the build.xml file, not in the Android SDK
>> >> Tools directory, because this change needs to work on all of my team's
>> >> machines and the build machine.  I'll try to find a solution and post
>> >> it here.
>>
>> > I've found the problem.  In the latest version of the Android SDK
>> > Tools (v8), the ${sdk}/tools/ant/main_rules.xml contains the build
>> > targets for regular Android projects built with Ant.  In this file,
>> > inside the <macrodef name="dex-helper"> element, there is a command
>> > which calls the application dx which creates the classes.dex file for
>> > you.  It is missing the external libs when called from the -dex
>> > target.   Right now, the ERRONEOUS program is run like:
>>
>> > java  -Xmx1024M -Djava.ext.dirs=lib\ -jar lib\dx.jar  --dex --output=C:
>> > \xxx\bin\classes.dex C:\xxx\bin\classes
>>
>> > However, it SHOULD be run including the external jar libraries as the
>> > source, along with the java class files:
>>
>> > java  -Xmx1024M -Djava.ext.dirs=lib\ -jar lib\dx.jar  --dex --output=C:
>> > \xxx\bin\classes.dex C:\xxx\bin\classes c:\xxx\lib\external_lib.jar
>>
>> > In order to fix this, you can do two things.  One, is to change the $
>> > {sdk}/tools/ant/main_rules.xml file yourself by changing the -dex
>> > target from:
>>
>> >        <if condition="${manifest.hasCode}">
>> >            <then>
>> >                <dex-helper />
>> >            </then>
>> >            <else>
>> >                <echo>hasCode = false. Skipping...</echo>
>> >            </else>
>> >        </if>
>>
>> > to:
>>
>> >        <if condition="${manifest.hasCode}">
>> >            <then>
>> >                <dex-helper>
>> >                        <external-libs>
>> >                        <path refid="jar.libs.ref" />
>> >                        </external-libs>
>> >                </dex-helper>
>> >            </then>
>> >            <else>
>> >                <echo>hasCode = false. Skipping...</echo>
>> >            </else>
>> >        </if>
>>
>> > Although that solution will work for most developers, it will not work
>> > if you need to propagate this fix across all team members working on
>> > the project.  As an alternative, you can fix it in your own project's
>> > build file (build.xml) by ensuring that the external .jar files are
>> > included in the input directory.  You can do this by copying the .jar
>> > files to the dex input directory before the dex target is called:
>>
>> >    <target name="-pre-compile">
>>
>> >        <!-- To fix a bug in Android SDK Tools v8, we need to copy the
>> > external
>> >             libraries to the binary output directory, so that the .jar
>> > is
>> >             included by the DX compiler. This will be unnecessary in the
>> > future
>> >             when the bug is fixed; see
>> >            http://code.google.com/p/android/issues/detail?id=13091. -->
>> >                <copy todir="${out.classes.absolute.dir}">
>> >                        <fileset dir="${jar.libs.absolute.dir}"/>
>> >                </copy>
>> >        </target>
>>
>> > If you fix it in your own build.xml file, then everyone who checks out
>> > the project will be able to build the project correctly, without
>> > having to change the SDK Tools local to their machine.
>>
>> > This is documented in the bug here:
>> >http://code.google.com/p/android/issues/detail?id=13091
>>
>> > --
>> > Matt Quigley
>> >www.androidengineer.com
>>
>> > --
>> > 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+unsubscribe@googlegroups.com
>> > For more options, visit this group at
>> >http://groups.google.com/group/android-developers?hl=en
>>
>> --
>> Xavier Ducrohet
>> Android SDK Tech Lead
>> Google Inc.
>>
>> Please do not send me questions directly. Thanks!
>
> --
> 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+unsubscribe@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.

Please do not send me questions directly. Thanks!

--
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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment