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
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
e scripts properly for
> not only Android, but my other platforms as well (non-Android
> platforms).
>
> Thanks again.
>
> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> > Either option can work fine. Disclosure: I work on Android Studio an
aps you added Java
> >> binding in those subprojects 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
> >> mistak
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 projects between
> bui
t to make sure I'm 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 <jomofis...@gmail.com&
+ a colleague
On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <jomofis...@gmail.com> 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)
> -
d? What about libraries like
> libgnustl_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 <jomofis
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 <jomofis...@gmail.com> wrote:
> Targets are specified per-Variation so they need to go under the
> variation-specific secti
t;, 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 <jomofis...@gmail.com>
think this should 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 <jomofis...@gmail.com>
> wrote:
> > Gradle does introspection on the CMake bu
inherited. Then 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 <jomofis...@gmail.com>
> wrote:
> > What you'r
encies 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 <jomofis...@gmail.com>
> wrote:
> > Would it work for your situation for the leaf CMakeLists.txt to inc
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
ile or directory:
'CMakeFiles/cmTC_0dcd8.dir/testCCompiler.c.o'
On Fri, Dec 29, 2017 at 7:02 AM, Ben Boeckel <ben.boec...@kitware.com>
wrote:
> On Thu, Dec 28, 2017 at 12:51:20 -0800, Jom O'Fisher wrote:
> > (1) Invoke cmake to generate ninja project. Success.
> >
I may have sent this on the wrong dl. I'm trying cm...@cmake.org
On Thu, Dec 28, 2017 at 12:44 PM, Jom O'Fisher <jomofis...@gmail.com> wrote:
> 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.
>
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
17 matches
Mail list logo
