I have an issue that's really difficult to track down because it only seems
to repro on certain machines which don't have access to.
The sequence of events seems to be:
(1) Invoke cmake to generate ninja project. Success.
* Note that generated rules.ninja has .o compilation dependencies with
absol
oject layout
so we can study it in more closely with an eye toward making the experience
better for this kind of layout.
On Fri, Aug 25, 2017 at 2:46 PM, Jom O'Fisher wrote:
> Targets are specified per-Variation so they need to go under the
> variation-specific section. Probably som
radle 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 proj
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
x27;re dealing with
> here. Your typical "hello world" project likely will have only 1
> CMakeLists.txt that is pretty self-contained, but all the
> documentation I've looked at so far doesn't show the best way to
> handle native library dependencies across java projec
rojects just for Android?
> >>
> >> The build.gradle in CommonLib, what kind of Gradle project is that?
> From
> >> your description, it doesn't look like an Android library project. Or
> am I
> >> mistaken and it also applies the android library plugin?
+ 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
not misunderstanding: Does
> each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?
> How many binary dirs do you manage internally and what determines when
> they get created?
>
> On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher
> wrote:
> > Would it
ncies to be built within it.
>
> If I'm misunderstanding or making false assumptions please let me know.
>
>
>
> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher
> wrote:
> > Would it work for your situation for the leaf CMakeLists.txt to include
> the
> &g
n only specify the differences (e.g. the native CMake
> target to build) in the leaf build gradle files. However you indicated
> this isn't possible.
>
>
>
> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher
> wrote:
> > What you're doing already sounds corr
d be
> put at the top-level build gradle file if possible. Is this doable at
> the moment? What is the recommended setup?
>
> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher
> wrote:
> > Gradle does introspection on the CMake build to find .so targets and
> those
> > ge
_shared.so that come with the NDK? I'd like to know if any
> manual copy steps are needed in CMake to put outputs in proper
> locations for the APK build step. I had to do this when using ANT.
>
> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher wrote:
> > 1) There is a folder
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
7;m going to try option 1 for now and see how it
> goes. It's just black box for me because unlike option 2, I have very
> little control over what happens after building the shared libraries,
> and to make up for that I need to really get a deep understanding of
> how it works so I can
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
15 matches
Mail list logo