Why does:
Interface Libraries
https://cmake.org/cmake/help/latest/command/add_library.html?highlight=add_library#id3
allow include directories via
target_include_directories(INTERFACE)
but not link_directories
https://cmake.org/cmake/help/latest/prop_dir/LINK_DIRECTORIES.html?highlight=link_di
+ 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
I think it is same as the issue.
I use Japanese version of Win10 Pro.
Regards.
Masaru.
2017年8月22日(火) 0:11 Brad King :
> On 08/21/2017 09:39 AM, Masaru Tsuchiyama wrote:
> > I did git bisect.
> >
> > The problematic commit is
> >
> https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5
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
On 08/21/2017 09:39 AM, Masaru Tsuchiyama wrote:
> I did git bisect.
>
> The problematic commit is
> https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58
>
> cmake with Ninja Generator succeeds by reverting
> 690acadc17263621f5361d48057c6f938e698a58
[snip]
>
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
Hello
I did git bisect.
The problematic commit is
https://gitlab.kitware.com/cmake/cmake/commit/690acadc17263621f5361d48057c6f938e698a58
cmake with Ninja Generator succeeds by reverting
690acadc17263621f5361d48057c6f938e698a58
> git checkout master
> git checkout -b try-revert-690acadc1726
Hello,
I am developing two llvm libraries (they should as MODULE .so at he end).
Still , they are situated in one cmake project and at some point I want to
use one pass (library) inside another. Simply including h files and getting
the result of llvm analysis leads to errors:
Error opening '../bui
16 matches
Mail list logo
