Open deguilardi opened 7 years ago
It seems that each build variant will generate its own libraries. Solution is to use prebuilt libs or use old external build script. Reference: https://stackoverflow.com/questions/43495127/gradle-android-single-ndk-build-for-multiple-flavors
@enrevol that's not correct. The folders build/intermitates/ndkBuild/FLAVOR/RELEASE/obj/local store the same libraries for every flavor/release. The libraries are all repetitions. And this behavior didn't happen on the version 3.14 or older.
cocos2d-x 3.15 uses a new build system, which is different from 3.14 and older versions.
@enrevol I know about the changes. But this behavior is not because of the build system, it's because of the way it is configured to build. There is no restrictions on gradle to build the libraries separately in a shared libs folder, one that every flavor can reach.
After building for development and production my build folder is 68 gigs. This is bad, very bad. I work on a mac pro with 6 3.5ghz xeon E5 cores and 16gb of memory, and the project takes 4 hours to compile ONLY because it compiles the entire cocos library for each flavor.
Can you imagine how bad it is on a standard quad-cored i5?
Before the update it used to take about 20 minutes.
Did you use gradle before?
yes, I use gradle for a long time. Gradle allows us to build a project a single time and use it as a sub project of infinite other projects. Instead of compiling the entire cocos library for each flavor, you can build it as a sub project. What I am not familiar is NDK build. If we find a way to build the cocos library inside the "cocos library" (libcocos2dx/build) every flavor will be able to load from there and this will make a HUGE difference on compiling time.
Sometimes all we need is update a library like facebook or admob. Why compile the whole thing so?
Steps to Reproduce:
issues: