I think I would prefer a strategy that uses the same-named build type, if
it exists, else use the library's defaultPublishConfig... As is, we
followed the mapping route (if I understand your post correctly), with
type-specific dependencies in our app build.gradle. With our custom build
type of preview, this is what we ended up with:
dependencies {
debugCompile project(path: ':myLib', configuration: 'debug')
previewCompile project(path: ':myLib', configuration: 'preview')
releaseCompile project(path: ':myLib', configuration: 'release')
compile (
'com.foo:extLib1:1.0'
'com.bar:extLib2:1.0'
)
}
Even with this, we had to set 'publishNonDefault true' in our library's
build.gradle to make Studio happy, which causes any build of any type of
our app to check on all build types of our library; most of the time,
everything's up to date, but it seems unnecessary. Is there a better way?
On Saturday, May 4, 2013 12:27:40 PM UTC-5, Xavier Ducrohet wrote:
>
> The library thing is normal. For now.
>
> For library project, "debug" and "release" are misnomer really (as I was
> preparing my I/O talk, I really wanted to rename them for 0.4, but so far I
> haven't)
>
> "debug" is used only for testing the library itself (so the test apk
> inside the library project uses this), and "release" is used to package the
> library for use by other projects (in a multi-project setup) or for upload
> to a repository.
>
> I think once we add NDK support we're going to want to change this and
> have possibly more than 2 built-in Build Types in Library Projects, but we
> have to figure out exactly what it's going to look like.
>
> For instance, do we enforce that Library Projects have exactly matching
> Build Types (in name) as the App Projects using them? This could become
> overly complex every time you add a new build type to your app, as you'd
> need to update all the Library Projects.
>
> Or we could have some mapping in the App project indicating (for each
> Build Type of the app!) which Build Type to use (for each library!). This
> could become unwieldy if you have many libraries (some developers have told
> me they were using 10, 20 library projects!).
>
> Ideas welcome.
>
> I'll check the assemble->bundleRelease extra dependency on Monday.
>
> thanks
> Xav
>
>
> On Sat, May 4, 2013 at 9:22 AM, Szabolcs Berecz <szabolc...@gmail.com
> <javascript:>> wrote:
>
>> Hi!
>>
>> I just noticed that assembleDebug creates an apk which contains the
>> release version of android-library projects, not the debug version. The
>> debug versions are also compiled for these library projects but only after
>> creating the apk, so there is no way to include the debug version of the
>> libraries in the apk.
>>
>> Is this intentional? Or maybe my build scripts are broken?
>>
>> I created a graph of the dependencies between all the tasks in my build
>> and this is what I see:
>> - in an 'android' project, the prepareReleaseDependencies and the
>> prepareDebugDependencies tasks depend on the same prepare*Library tasks
>> which in turn depend on bundleRelease tasks
>> - bundleDebug tasks are only depended on by assembleDebug which are only
>> depended on by assemble. So, nothing uses the results of a debug build of
>> an android-library project. Or if something uses it, it does not show in
>> the task dependencies.
>>
>> I also noticed that there is an unnecessary dependency between assemble
>> and bundleRelease. Assemble also depends on assembleRelease which depends
>> on bundleRelease, therefore the assemble->bundleRelease dependency is
>> unnecessary.
>>
>> I can minimize my build if that helps. Let me know if you need it.
>>
>> Thanks,
>> Szabolcs
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "adt-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to adt-dev+u...@googlegroups.com <javascript:>.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
>
>
> --
> Xavier Ducrohet
> Android SDK Tech Lead
> Google Inc.
> http://developer.android.com | http://tools.android.com
>
> Please do not send me questions directly. Thanks!
>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to adt-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
