I could probably do you one better, and just give you a stripped-down
version of our repository. Basically, I'd remove all our C++ and Java
source code but leave the CMake scripts and such intact somehow. It
would take me some time to do this, though. Would this be helpful for
you?
In the meantime
Hi again Robert,
Would you be able to give me an estimate of how many APK projects you have,
roughly which open source projects you reference via CMake
add_subdirectories, and whether you have any variants beyond the default
Debug and Release? If possible I'd like to approximate your project layout
Targets are specified per-Variation so they need to go under the
variation-specific section. Probably something like this:
defaultConfig {
externalNativeBuild {
cmake {
targets "library1", "
By the way when I try to use "targets", I get a failure. Basically
Gradle doesn't recognize that keyword. I tried singular form as well
("target"), no luck.
I'm running canary build of everything possible. What am I missing?
On Wed, Aug 23, 2017 at 4:20 PM, Jom O'Fisher wrote:
> By gradle module
Thanks for explaining, as usual your answers are making things much more clear.
When it's all said and done and considering everything we've discussed
up to this point, I'm fine with how you've architected the CMake
integration with Gradle. I think the way things function is perfectly
fine. My onl
Thanks Craig, I hadn't found that article yet
On Wed, Aug 23, 2017 at 4:37 PM, Craig Scott
wrote:
>
>
> On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisher
> wrote:
>
>> We'll definitely be discussing this use case at our next C++ meeting and
>> I'll also be checking for myself whether ccache will wo
On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisher wrote:
> We'll definitely be discussing this use case at our next C++ meeting and
> I'll also be checking for myself whether ccache will work in this CMake
> scenario. If ccache does work it seems like the natural level at which to
> fold identical bu
By gradle module projects, I just mean the leaf build.gradle files as
opposed to the root build.gradle. By configurations, I mean Build Types
(debug vs release) and Product Flavors (demo vs free vs paid). Hereafter I
will use the term "variant" rather than "configuration" to be precise. See
this wr
I'm not sure what you mean by "gradle module projects", but maybe
having some examples of what you mean by "configurations, C++ flags,
etc" might make it more clear.
Question: When specifying "path" for the CMakeLists.txt in the
build.gradle file, how do you know which targets to build? For
exampl
Thanks for the write-up Robert. Having thought about it, I don't believe we
have a satisfying answer at the gradle level for this kind of organization.
In the gradle model module projects are the unit of organization for
configurations, C/C++ flags, etc. and that's something we're pretty much
stuck
Another reason to reduce the number of binary directories is that
there are different ways of managing third party libraries. One in
particular that we use is to clone a repository into the binary
directory and build all third party libs in real time based on a
toolchain file (Similar to the functi
Sorry I forgot to answer your last set of questions:
CommonLib is indeed 2 things:
* A common (static or shared) library for native code (most of our
CMake targets specify CommonLib as a link dependency)
* A common library for Java code (we do specify this as a dependency
for most java targets in
Thanks to both of you for responding.
First, to Jom's reply: The "x" part is what I was worried about. Each
"path" resulting in a single binary dir. This is the part that I think
could be optimized. I'll explain more on this later. Note also that
this optimization might only benefit my specific st
+ a colleague
On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher wrote:
> You can find that number like this:
> - x = number of externalNativeBuild.cmake.path in your build.gradle files
> - y = number of gradle configurations (like debug and release)
> - z = number of ABIs that you build
>
> The resu
You can find that number like this:
- x = number of externalNativeBuild.cmake.path in your build.gradle files
- y = number of gradle configurations (like debug and release)
- z = number of ABIs that you build
The result is x * y * z. To be more accurate, you should consider y and z
to be functions
This definitely a bit better, but still requires the boilerplate in
each leaf gradle file. But I can't seriously complain too much. I
think I'm more concerned with the implications this has underneath.
First, let me ask just to make sure I'm not misunderstanding: Does
each `externalNativeBuild` ent
Would it work for your scenario to provide properties in the root
build.gradle:
ext {
cmakePath = file "CMakeLists.txt"
}
And then consume them in the leaf app/build.gradle like this?
externalNativeBuild {
cmake {
path cmakePath
}
}
It doesn't fully hide the details but it d
I wouldn't want to do that, it's too convoluted. I have other
platforms that use these CMake scripts as well. For example, I run on
Windows and Linux platforms as well to build the native code. Normal
CMake behavior is designed to work at a root then go downwards to find
targets. However it seems G
Would it work for your situation for the leaf CMakeLists.txt to include the
root CMakeLists.txt? Then have the leaf-specific logic in the leaf
CMakeLists.txt?
On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey
wrote:
> Basically, yes. We have this sort of structure:
>
> /
> Applications/
>
Basically, yes. We have this sort of structure:
/
Applications/
App1/
build.gradle
CMakeLists.txt
App2/
build.gradle
CMakeLists.txt
App3/
build.gradle
CMakeLists.txt
CommonLib/
build.gra
What you're doing already sounds correct. You can't directly specify
CMakeLists.txt from the top-level build.gradle. Recommendation is that it
should be specified from the build.gradle of the module of the APK. Is the
issue that you have multiple APK modules that all reference the same CMake
librar
Thanks this is very helpful. The other question I have is: Is there a
place to centrally specify the root CMakeLists.txt? Basically, I want
to specify the CMake root in 1 place, and have targets (defined
further down in subdirectories) that require APK packaging to specify
only the native target na
Gradle does introspection on the CMake build to find .so targets and those
get packaged.
There is also a special case for stl/runtime .so files from the NDK.
Any additional .so files need to specified in build.gradle using jniDirs
On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey
wrote:
> How exact
How exactly does Gradle package *.so files in an APK? I know that ANT
used to do this for any libs under "libs/". Does Gradle do some
introspection into CMake targets to see if outputs are *.so, and copy
those to some location if needed? What about libraries like
libgnustl_shared.so that come with
On 8/8/17, Jom O'Fisher wrote:
> Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the
> first version to support server mode). So your fork would need to be based
> on a somewhat recent CMake. We probably wouldn't support a path directly in
> build.gradle since that is typical
Yeah, we'd like to support any CMake more recent than 3.7.0 (which is the
first version to support server mode). So your fork would need to be based
on a somewhat recent CMake. We probably wouldn't support a path directly in
build.gradle since that is typically a source controlled artifact. We'd le
Hi Jom,
I'm glad to hear Android's CMake will eventually catch up.
But since you are here, can you add a feature that allows a user to
specify an alternate location for where CMake is located? There are
two useful cases for this.
1) Users daring or desperate enough to try using a more recent CMa
1) There is a folder created for each ABI under the project module folder
(so unique per module per ABI)
2) Gradle doesn't specify language level though you can choose to specify
it yourself from the build.gradle. This doc does a pretty good job of
explaining which variables are set by Gradle:
http
Thanks Jom
Honestly, I prefer option 1 to work simply because that's how Google's
officially supporting CMake. But it also has debugging which is the #1
reason for me.
However, I'd like to understand a lot more about how the integration
really happens. For example, I have these questions:
1) How
Either option can work fine. Disclosure: I work on Android Studio and was
the one that added CMake support.
Option (1) is the way it's designed to work and we're working toward
getting rid of the need for the CMake fork. I can't really say when that
will happen but if you can get away with an olde
Right now I have custom targets set to execute the "ant release"
command after my native targets are built. Part of that command
involves copying *.so files to the libs/armeabi-v7a directory so they
get packaged in an APK.
When switching to gradle, I have two options:
1. Gradle drives CMake: This
31 matches
Mail list logo