-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
hello-libs sample doesn't seem to take into account build types #576
Comments
No the debug types. the build lib is debug build ( not the release build ). The thought behind that is:
|
I am not sure that I see your point. Gradle produces "debug" and "release" folders for each library, doesn't it? But then they are smashed into the same output directory which may or may not be an issue. But for demonstration purposes I think that it makes sense to put the binaries into separate directories e.g. debug, release... etc. |
that line is for application to use lib, NOT to produce the lib. The purpose of the application to show that even when building debug version of application, it still use the "release" version of 3rd party lib. The assumption is that 3rd party lib providers will just provide one version of lib, NOT mixing them into the same dir. |
Well, then it may be reasonable to explain that explicitly why and how in the documentation. |
Just a suggestion: another valuable sample would be to show how to do all of this in the gradle script:
so that the user could just drop in a library source and use it without modifying the library's CMakeLists.txt |
yeah, it is good point. The original thought is:
Gradle's copy function is pretty easy and flexible; the potential though is that it needs to know where the files to copy from -- this directory info is from CMake. So here logic crosses the boundaries again... From the build script standing point of view, the minimum crosses between gradle and cmake ( or other native build systems ) would be the best. CMake installation step might do a better work to copy: basically this is similar to install the header & libs into certain place. There is discussion about that approach, probably should explore that path too. |
How can this be done from Gradle? The idea is if you have libraries' source code, which you can include in your project for example as a library modules, which then you can add as dependencies of the app module. You also don't want to touch the libraries original CMakeLists.txt. So I want to set ARCHIVE_OUTPUT_DIRECTORY and LIBRARY_OUTPUT_DIRECTORY from Gradle. |
asking the equivalent variables in gradle for them as I do not think Gradle could access CMake variables. |
I think you misunderstand me. I don't want to access CMake variables from gradle. What I want is to pass the values set in ANDROID_ABI and CMAKE_BUILD_TYPE myself in the gradle script and pass them to CMake which I guess are passed to CMake by gradle somehow.
I think it would be best if I can set ARCHIVE_OUTPUT_DIRECTORY, LIBRARY_OUTPUT_DIRECTORY from gradle itself but I cannot figure out how to get the build type, and the abi and to pass them to |
understood, @jomof might know those variables in gradle. |
The sample doesn't seem to take into account the various build types (debug, release)
set(distribution_DIR ${CMAKE_SOURCE_DIR}/../../../../distribution)
That doesn't seem right to me.
The text was updated successfully, but these errors were encountered: