This was totally helpful knowlege, but still I recommend you to provide more information of soong documentation. It's better to have an FAQ or small documentation on manual convertion of Android.mk to Android.bp. Am happy with Android 9, since it gives more information on bugs found in bp files.
- Shakir On Wednesday, 29 May 2019 07:59:11 UTC+5:30, Dan Willemsen wrote: > > Comments inline: > > On Tue, May 28, 2019 at 11:21 AM Shakir Mohammed <[email protected] > <javascript:>> wrote: > >> Hi, >> Am trying to convert all my Android.mk files which are actually designed >> in hierarchical manner using several Android.mk files. I have total 60 >> Android.mk files which are linked to each other. Am using a global make >> file to provide configuration variables to each make files. >> > > We've found that variables generally haven't been that useful -- careful > application of (cc|java)_defaults, and/or a bit of refactoring goes a long > way to not needing them at all. Plus, that simplifies how many combinations > of builds that you need to run in your CI systems to ensure that a change > won't break a build (in addition to making your code easier to understand). > > Currently I need to convert it to Android.bp so that I could use "vndk", >> "vendor_available", etc. >> > > These concepts only exist for the cc_* (C/C++) rules, they don't apply to > Java-based rules. > > "vndk" is something that really should only be set by the upstream > project, as it's defining an ABI guarantee between different distributable > pieces. > > "vendor_available" is mostly just a shortcut to define a module twice, > once with vendor: true, and once without. It's possible to emulate that in > Make. > > >> Am facing "Internal error: not yet implemented" error in Android 8.1 for >> some modules and it crashed total Android make/mmm system. And then I have >> shifted to Android 9. >> > > Java support in Android.bp was very broken in 8.1 -- it was an old > prototype while we focused on the cc_* modules. If I remember correctly, > there was minimal support for Java in Android.bp in 9, but it's much much > better in Android Q (with a few advancements in master -- in particular, > JNI support for android_app didn't make it in for Q, but should mostly work > in AOSP master). > > >> Now am getting all properly but am in slight confusion on how to get >> proper tutorial on Android.bp generation. Some of my requirements are as >> follows, >> >> # How to use LOCAL_JNI_SHARED_LIBS in android_app module, which is not >> getting converted using androidmk tool. >> > > In master, you can use the jni_libs property on android_app: > https://ci.android.com/builds/submitted/5612488/linux/latest/java.html#android_app.jni_libs > > In earlier versions of Android, you'll need to stick with Android.mk for > that module. > > >> # Perform condition checks using some custom variable with custom option >> in each modules. >> > > We really encourage you not to do condition checks, they make your build > significantly more complicated. Here's our FAQ entry: > > > https://android.googlesource.com/platform/build/soong/+/master#how-do-i-write-conditionals > > If you want/need to ignore this advice, we do support passing through > specific variables from Make to Go, where you'd need to write your own > soong module type in Go: > https://android.googlesource.com/platform/build/soong/+/0fe7866897b177f2bf7ec934c5615a2b48e48a23. > > There are a number of examples of soong plugins in the tree, but no public > ones that use the SOONG_CONFIG_* feature -- they're usually doing something > special, or making changes based on environment variables (which aren't > useful for device-specific configuration, but for certain temporary cases > can be useful). > > >> # How not to jump in to some subdirectories, which I haven't specified in >> subdir variable. >> # What is the difference between subdir and optional_subdir. >> > > As of Android 9 (I don't think it made 8.1), all Android.bp files found in > the tree will always be loaded no matter what, there is no way to > conditionally load the files. > > As a replacement for conditional loading, we added the concept of soong > namespaces, so that you can define two modules of the same name, as long as > the two namespaces that they're defined within aren't selected by the > current device. We've got some (minimal) documentation here: > https://android.googlesource.com/platform/build/soong/+/master/README.md#name-resolution. > > Many of the devices in AOSP now use this. > > >> # How to pass some varibles between bp files. Some variables are getting >> passed whereas others are not. >> > > They're passed down between bp files based on the filesystem layout, so if > you define a variable in foo/Android.bp, foo/bar/Android.bp and > foo/a/b/Android.bp will be able to read it, but baz/Android.bp will not see > it. (It will be considered read-only after it has been used within the > Android.bp that defined it, and always read-only in other Android.bp files). > > - Dan > > >> >> -- >> -- >> You received this message because you are subscribed to the "Android >> Building" mailing list. >> To post to this group, send email to [email protected] >> <javascript:> >> To unsubscribe from this group, send email to >> [email protected] <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/android-building?hl=en >> >> --- >> You received this message because you are subscribed to the Google Groups >> "Android Building" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/android-building/1f1ffcf8-6058-4df4-8dcb-e33f4d4f0be3%40googlegroups.com >> >> <https://groups.google.com/d/msgid/android-building/1f1ffcf8-6058-4df4-8dcb-e33f4d4f0be3%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- -- You received this message because you are subscribed to the "Android Building" mailing list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-building?hl=en --- You received this message because you are subscribed to the Google Groups "Android Building" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/android-building/5a5f58e4-7ce9-4c63-8db4-5b60d0c1fa62%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
