[CMake] Interface Libraries allow include directories but not link directories.. Why?
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_directories which if we look at property scope: https://cmake.org/cmake/help/latest/manual/cmake-properties.7.html Why is include_directories at target resolution while link_directories is at directory resolution. link_directories is a property on a directory which if I recalled correctly I complained about many many moons ago (circa 2009) when I first realized this. I did not understand this logic then and don't understand this logic now. Someone what to give me the recipe for the CMake cool-aid so I can mix that up, drink it down, and re-read the doc and finally come to terms with this. Or could the powers that be redesign CMake to make sense. At the time I wrapped this nonsense in a macro and pretended it did not happen ... now I am rewriting my project for "new" CMake and still don't get this. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake + Gradle for Android
+ 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 result is x * y * z. To be more accurate, you should consider y and z
> to be functions of each build.gradle file since these can vary.
>
> There is a second set of folders that hold the stripped versions of the
> .so files that is purely managed by the android gradle plugin, so you might
> consider the answer to be 2 * x * y * z.
>
> Hope this helps.
>
>
>
>
>
>
> On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey
> wrote:
>
>> 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` 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 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 does centralize the
>> information.
>> >
>> >
>> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <
>> rcdailey.li...@gmail.com>
>> > wrote:
>> >>
>> >> 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 Gradle wants to start at a subdirectory and
>> >> work its way up to the root, which is opposite of CMake's intended
>> >> behavior IMHO. Not only that but I want to avoid special-casing
>> >> behavior in CMake just for Android's use.
>> >>
>> >> At the moment it feels like (again referring back to my previous
>> >> example structure) that both App2 and App3 each run CMake in
>> >> independent binary directories instead of sharing 1 binary directory
>> >> and building 2 targets inside of it. I prefer this behavior instead,
>> >> especially since it allows CMake to operate as it was intended. I
>> >> think it's a common case that projects will define multiple targets
>> >> starting from a single root, and expect multiple APKs or java
>> >> dependencies 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
>> >> > 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/
>> >> >> App1/
>> >> >> build.gradle
>> >> >> CMakeLists.txt
>> >> >> App2/
>> >> >> build.gradle
>> >> >> CMakeLists.txt
>> >> >> App3/
>> >> >> build.gradle
>> >> >> CMakeLists.txt
>> >> >> CommonLib/
>> >> >> build.gradle
>> >> >> CMakeLists.txt
>> >> >> CMakeLists.txt
>> >> >>
>> >> >> The libs are defined as follows:
>> >> >>
>> >> >> * CommonLib is a static library (java code builds into a library)
>> >> >> * No dependencies of its own
>> >> >> * App1 is a shared library (java code builds into a library)
>> >> >> * Dependencies (both java & native): CommonLib
>> >> >> * App2 is a shared library (java code builds into an APK)
>> >> >>* Dependencies (both java & native): App1, CommonLib
>> >> >> * App3 is a shared library (java code builds into an APK)
>> >> >>* Dependencies (both java & native): CommonLib
>> >> >>
>> >> >> In all cases, CMake must be invoked starting at the root
>> >> >> CMakeLists.txt 1 time. Each target can be built from the same binary
>> >> >> directory after that. Previously with ANT, I was building all native
>> >> >> targets first, then moved libs to appropriate directories so that
>> the
>> >> >> 'ant' command would package the libs.
>> >> >>
>> >> >> For gradle, I wanted to avoid redundantly specifying the root
>> >> >> directory in each leaf-level project directory. Using the example
>> >> >> above, the leaf-level directories in this case would be App1, App2,
>
Re: [CMake] CMake + Gradle for Android
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 of each build.gradle file since these can vary.
There is a second set of folders that hold the stripped versions of the .so
files that is purely managed by the android gradle plugin, so you might
consider the answer to be 2 * x * y * z.
Hope this helps.
On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey
wrote:
> 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` 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 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 does centralize the information.
> >
> >
> > On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <
> rcdailey.li...@gmail.com>
> > wrote:
> >>
> >> 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 Gradle wants to start at a subdirectory and
> >> work its way up to the root, which is opposite of CMake's intended
> >> behavior IMHO. Not only that but I want to avoid special-casing
> >> behavior in CMake just for Android's use.
> >>
> >> At the moment it feels like (again referring back to my previous
> >> example structure) that both App2 and App3 each run CMake in
> >> independent binary directories instead of sharing 1 binary directory
> >> and building 2 targets inside of it. I prefer this behavior instead,
> >> especially since it allows CMake to operate as it was intended. I
> >> think it's a common case that projects will define multiple targets
> >> starting from a single root, and expect multiple APKs or java
> >> dependencies 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
> >> > 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/
> >> >> App1/
> >> >> build.gradle
> >> >> CMakeLists.txt
> >> >> App2/
> >> >> build.gradle
> >> >> CMakeLists.txt
> >> >> App3/
> >> >> build.gradle
> >> >> CMakeLists.txt
> >> >> CommonLib/
> >> >> build.gradle
> >> >> CMakeLists.txt
> >> >> CMakeLists.txt
> >> >>
> >> >> The libs are defined as follows:
> >> >>
> >> >> * CommonLib is a static library (java code builds into a library)
> >> >> * No dependencies of its own
> >> >> * App1 is a shared library (java code builds into a library)
> >> >> * Dependencies (both java & native): CommonLib
> >> >> * App2 is a shared library (java code builds into an APK)
> >> >>* Dependencies (both java & native): App1, CommonLib
> >> >> * App3 is a shared library (java code builds into an APK)
> >> >>* Dependencies (both java & native): CommonLib
> >> >>
> >> >> In all cases, CMake must be invoked starting at the root
> >> >> CMakeLists.txt 1 time. Each target can be built from the same binary
> >> >> directory after that. Previously with ANT, I was building all native
> >> >> targets first, then moved libs to appropriate directories so that the
> >> >> 'ant' command would package the libs.
> >> >>
> >> >> For gradle, I wanted to avoid redundantly specifying the root
> >> >> directory in each leaf-level project directory. Using the example
> >> >> above, the leaf-level directories in this case would be App1, App2,
> >> >> App3, and CommonLib. However I think we only specify the native CMake
> >> >> stuff for the java targets that actually output an APK (that would be
> >> >> App2 and App3 only).
> >> >>
> >> >> The ultimate goa
Re: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1
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/690acadc17263621f5361d48057c6f938e698a58 > > > > cmake with Ninja Generator succeeds by reverting > > 690acadc17263621f5361d48057c6f938e698a58 > [snip] > >ninja: error: build.ninja:30: loading 'rules.ninja': > >指定されたファイルが見つかりません。 > > Thanks. Is that this issue? > > https://gitlab.kitware.com/cmake/cmake/issues/17191 > > Otherwise, please open a new issue. > > Thanks, > -Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake + Gradle for Android
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` 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 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 does centralize the information.
>
>
> On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey
> wrote:
>>
>> 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 Gradle wants to start at a subdirectory and
>> work its way up to the root, which is opposite of CMake's intended
>> behavior IMHO. Not only that but I want to avoid special-casing
>> behavior in CMake just for Android's use.
>>
>> At the moment it feels like (again referring back to my previous
>> example structure) that both App2 and App3 each run CMake in
>> independent binary directories instead of sharing 1 binary directory
>> and building 2 targets inside of it. I prefer this behavior instead,
>> especially since it allows CMake to operate as it was intended. I
>> think it's a common case that projects will define multiple targets
>> starting from a single root, and expect multiple APKs or java
>> dependencies 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
>> > 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/
>> >> App1/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> App2/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> App3/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> CommonLib/
>> >> build.gradle
>> >> CMakeLists.txt
>> >> CMakeLists.txt
>> >>
>> >> The libs are defined as follows:
>> >>
>> >> * CommonLib is a static library (java code builds into a library)
>> >> * No dependencies of its own
>> >> * App1 is a shared library (java code builds into a library)
>> >> * Dependencies (both java & native): CommonLib
>> >> * App2 is a shared library (java code builds into an APK)
>> >>* Dependencies (both java & native): App1, CommonLib
>> >> * App3 is a shared library (java code builds into an APK)
>> >>* Dependencies (both java & native): CommonLib
>> >>
>> >> In all cases, CMake must be invoked starting at the root
>> >> CMakeLists.txt 1 time. Each target can be built from the same binary
>> >> directory after that. Previously with ANT, I was building all native
>> >> targets first, then moved libs to appropriate directories so that the
>> >> 'ant' command would package the libs.
>> >>
>> >> For gradle, I wanted to avoid redundantly specifying the root
>> >> directory in each leaf-level project directory. Using the example
>> >> above, the leaf-level directories in this case would be App1, App2,
>> >> App3, and CommonLib. However I think we only specify the native CMake
>> >> stuff for the java targets that actually output an APK (that would be
>> >> App2 and App3 only).
>> >>
>> >> The ultimate goal is to specify stuff that doesn't change per
>> >> independent "module" of ours at the top level so it is transitive /
>> >> 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
>> >> wrote:
>> >> > 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
>> >> > libraries?
>> >> >
>> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
>> >> >
>> >> > wrote:
>> >> >>
>>
Re: [CMake] CMake + Gradle for Android
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 does centralize the information.
On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey
wrote:
> 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 Gradle wants to start at a subdirectory and
> work its way up to the root, which is opposite of CMake's intended
> behavior IMHO. Not only that but I want to avoid special-casing
> behavior in CMake just for Android's use.
>
> At the moment it feels like (again referring back to my previous
> example structure) that both App2 and App3 each run CMake in
> independent binary directories instead of sharing 1 binary directory
> and building 2 targets inside of it. I prefer this behavior instead,
> especially since it allows CMake to operate as it was intended. I
> think it's a common case that projects will define multiple targets
> starting from a single root, and expect multiple APKs or java
> dependencies 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
> > 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/
> >> App1/
> >> build.gradle
> >> CMakeLists.txt
> >> App2/
> >> build.gradle
> >> CMakeLists.txt
> >> App3/
> >> build.gradle
> >> CMakeLists.txt
> >> CommonLib/
> >> build.gradle
> >> CMakeLists.txt
> >> CMakeLists.txt
> >>
> >> The libs are defined as follows:
> >>
> >> * CommonLib is a static library (java code builds into a library)
> >> * No dependencies of its own
> >> * App1 is a shared library (java code builds into a library)
> >> * Dependencies (both java & native): CommonLib
> >> * App2 is a shared library (java code builds into an APK)
> >>* Dependencies (both java & native): App1, CommonLib
> >> * App3 is a shared library (java code builds into an APK)
> >>* Dependencies (both java & native): CommonLib
> >>
> >> In all cases, CMake must be invoked starting at the root
> >> CMakeLists.txt 1 time. Each target can be built from the same binary
> >> directory after that. Previously with ANT, I was building all native
> >> targets first, then moved libs to appropriate directories so that the
> >> 'ant' command would package the libs.
> >>
> >> For gradle, I wanted to avoid redundantly specifying the root
> >> directory in each leaf-level project directory. Using the example
> >> above, the leaf-level directories in this case would be App1, App2,
> >> App3, and CommonLib. However I think we only specify the native CMake
> >> stuff for the java targets that actually output an APK (that would be
> >> App2 and App3 only).
> >>
> >> The ultimate goal is to specify stuff that doesn't change per
> >> independent "module" of ours at the top level so it is transitive /
> >> 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
> >> wrote:
> >> > 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
> >> > libraries?
> >> >
> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey
> >> >
> >> > wrote:
> >> >>
> >> >> 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 name that should be built & packaged.
> >> >>
> >> >> At the moment we specify the root CMakeLists.txt by walking up the
> >> >> tree, paths like "../../../../CMakeLists.txt". I think this should be
> >> >> put at the top-level build gradle file if possible. Is this doable at
> >> >> the moment? What is
Re: [CMake] CMake + Gradle for Android
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 Gradle wants to start at a subdirectory and work its way up to the root, which is opposite of CMake's intended behavior IMHO. Not only that but I want to avoid special-casing behavior in CMake just for Android's use. At the moment it feels like (again referring back to my previous example structure) that both App2 and App3 each run CMake in independent binary directories instead of sharing 1 binary directory and building 2 targets inside of it. I prefer this behavior instead, especially since it allows CMake to operate as it was intended. I think it's a common case that projects will define multiple targets starting from a single root, and expect multiple APKs or java dependencies 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 > 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/ >> App1/ >> build.gradle >> CMakeLists.txt >> App2/ >> build.gradle >> CMakeLists.txt >> App3/ >> build.gradle >> CMakeLists.txt >> CommonLib/ >> build.gradle >> CMakeLists.txt >> CMakeLists.txt >> >> The libs are defined as follows: >> >> * CommonLib is a static library (java code builds into a library) >> * No dependencies of its own >> * App1 is a shared library (java code builds into a library) >> * Dependencies (both java & native): CommonLib >> * App2 is a shared library (java code builds into an APK) >>* Dependencies (both java & native): App1, CommonLib >> * App3 is a shared library (java code builds into an APK) >>* Dependencies (both java & native): CommonLib >> >> In all cases, CMake must be invoked starting at the root >> CMakeLists.txt 1 time. Each target can be built from the same binary >> directory after that. Previously with ANT, I was building all native >> targets first, then moved libs to appropriate directories so that the >> 'ant' command would package the libs. >> >> For gradle, I wanted to avoid redundantly specifying the root >> directory in each leaf-level project directory. Using the example >> above, the leaf-level directories in this case would be App1, App2, >> App3, and CommonLib. However I think we only specify the native CMake >> stuff for the java targets that actually output an APK (that would be >> App2 and App3 only). >> >> The ultimate goal is to specify stuff that doesn't change per >> independent "module" of ours at the top level so it is transitive / >> 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 >> wrote: >> > 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 >> > libraries? >> > >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey >> > >> > wrote: >> >> >> >> 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 name that should be built & packaged. >> >> >> >> At the moment we specify the root CMakeLists.txt by walking up the >> >> tree, paths like "../../../../CMakeLists.txt". I 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 >> >> wrote: >> >> > 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 exactly does Gradle package *.so files in an APK? I know that >> >> >> ANT >> >> >> used to do this for any libs under "li
Re: [CMake] CMake + Gradle for Android
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/ > App1/ > build.gradle > CMakeLists.txt > App2/ > build.gradle > CMakeLists.txt > App3/ > build.gradle > CMakeLists.txt > CommonLib/ > build.gradle > CMakeLists.txt > CMakeLists.txt > > The libs are defined as follows: > > * CommonLib is a static library (java code builds into a library) > * No dependencies of its own > * App1 is a shared library (java code builds into a library) > * Dependencies (both java & native): CommonLib > * App2 is a shared library (java code builds into an APK) >* Dependencies (both java & native): App1, CommonLib > * App3 is a shared library (java code builds into an APK) >* Dependencies (both java & native): CommonLib > > In all cases, CMake must be invoked starting at the root > CMakeLists.txt 1 time. Each target can be built from the same binary > directory after that. Previously with ANT, I was building all native > targets first, then moved libs to appropriate directories so that the > 'ant' command would package the libs. > > For gradle, I wanted to avoid redundantly specifying the root > directory in each leaf-level project directory. Using the example > above, the leaf-level directories in this case would be App1, App2, > App3, and CommonLib. However I think we only specify the native CMake > stuff for the java targets that actually output an APK (that would be > App2 and App3 only). > > The ultimate goal is to specify stuff that doesn't change per > independent "module" of ours at the top level so it is transitive / > 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 > wrote: > > 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 > > libraries? > > > > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > > > wrote: > >> > >> 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 name that should be built & packaged. > >> > >> At the moment we specify the root CMakeLists.txt by walking up the > >> tree, paths like "../../../../CMakeLists.txt". I 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 > >> wrote: > >> > 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 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 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 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: > >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. > >> >> > Philosophically, we try to set as little as we can get away with. > In > >> >> > particular, the section titled "Understanding the CMake build > >> >> > command" > >> >> > lays > >> >> > out exactly what we set. You can also see the folders we specify > (one > >> >> > per > >> >> > module per ABI) > >> >> > 3) Not sure I understand this. > >> >> > > >>
Re: [CMake] CMake + Gradle for Android
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.gradle CMakeLists.txt CMakeLists.txt The libs are defined as follows: * CommonLib is a static library (java code builds into a library) * No dependencies of its own * App1 is a shared library (java code builds into a library) * Dependencies (both java & native): CommonLib * App2 is a shared library (java code builds into an APK) * Dependencies (both java & native): App1, CommonLib * App3 is a shared library (java code builds into an APK) * Dependencies (both java & native): CommonLib In all cases, CMake must be invoked starting at the root CMakeLists.txt 1 time. Each target can be built from the same binary directory after that. Previously with ANT, I was building all native targets first, then moved libs to appropriate directories so that the 'ant' command would package the libs. For gradle, I wanted to avoid redundantly specifying the root directory in each leaf-level project directory. Using the example above, the leaf-level directories in this case would be App1, App2, App3, and CommonLib. However I think we only specify the native CMake stuff for the java targets that actually output an APK (that would be App2 and App3 only). The ultimate goal is to specify stuff that doesn't change per independent "module" of ours at the top level so it is transitive / 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 wrote: > 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 > libraries? > > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey > wrote: >> >> 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 name that should be built & packaged. >> >> At the moment we specify the root CMakeLists.txt by walking up the >> tree, paths like "../../../../CMakeLists.txt". I 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 >> wrote: >> > 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 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 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 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: >> >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> >> > Philosophically, we try to set as little as we can get away with. In >> >> > particular, the section titled "Understanding the CMake build >> >> > command" >> >> > lays >> >> > out exactly what we set. You can also see the folders we specify (one >> >> > per >> >> > module per ABI) >> >> > 3) Not sure I understand this. >> >> > >> >> > The other document worth taking a look at (if you haven't already) >> >> > is: >> >> > https://developer.android.com/studio/projects/add-native-code.html >> >> > >> >> > >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> >> > >> >> > wrote: >> >> >> >> >> >> Thanks Jom >> >> >> >> >> >> Honestly, I prefer option 1 to work simply because that's how >> >> >> Google's >> >> >> officially supporting CMake. But it also has debugging
Re: [CMake] CMake + Gradle for Android
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 libraries? On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey wrote: > 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 name that should be built & packaged. > > At the moment we specify the root CMakeLists.txt by walking up the > tree, paths like "../../../../CMakeLists.txt". I 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 > wrote: > > 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 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 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 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: > >> > https://developer.android.com/ndk/guides/cmake.html#variables. > >> > Philosophically, we try to set as little as we can get away with. In > >> > particular, the section titled "Understanding the CMake build command" > >> > lays > >> > out exactly what we set. You can also see the folders we specify (one > >> > per > >> > module per ABI) > >> > 3) Not sure I understand this. > >> > > >> > The other document worth taking a look at (if you haven't already) is: > >> > https://developer.android.com/studio/projects/add-native-code.html > >> > > >> > > >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey < > rcdailey.li...@gmail.com> > >> > wrote: > >> >> > >> >> 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, internally, are CMake build directories managed? Do you > >> >> generate 1 per unique android project? What about for each specific > >> >> platform (x86, armeabi-v7a, etc)? > >> >> 2) Last time I looked into CMake integration, things defined inside > >> >> the CMake scripts were ignored because they are specified at the > >> >> command line. Namely, all of those settings that are driven by the > >> >> Gradle configuration (CXX language level was one in particular I > >> >> think; I specify C++14 support via CMake, but I recall this being > >> >> overridden from outside)? > >> >> 3) How redundant is it to configure individual libraries via the > >> >> gradle scripts? In my previous attempts, I wanted to define common > >> >> stuff for CMake / native code at the root gradle or settings file, > and > >> >> only define the differences in the actual gradle build files for each > >> >> corresponding Java target (like, defining the name of the native > >> >> (shared library) target in Gradle, but the command line invocation, > -D > >> >> CMake settings, etc would all be common and defined at the root). > >> >> > >> >> The TLDR is, the closer we can stay to CMake's way of doing things > and > >> >> keep CMake-related settings self-contained to the CMake scripts > >> >> themselves, the better. This also makes cross-platform easier (we > >> >> build the native code in Windows, for example, so having settings > >> >> specified in the gradle files do not carry over to other platforms. > >> >> Namely, settings that are not platform specific like the C++ language > >> >> level). > >> >> > >> >> If there's a detailed document / wiki I can read on the intrinsics of > >> >> CMake integr
Re: [CMake] CMake + Gradle for Android
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 name that should be built & packaged. At the moment we specify the root CMakeLists.txt by walking up the tree, paths like "../../../../CMakeLists.txt". I 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 wrote: > 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 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 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 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: >> > https://developer.android.com/ndk/guides/cmake.html#variables. >> > Philosophically, we try to set as little as we can get away with. In >> > particular, the section titled "Understanding the CMake build command" >> > lays >> > out exactly what we set. You can also see the folders we specify (one >> > per >> > module per ABI) >> > 3) Not sure I understand this. >> > >> > The other document worth taking a look at (if you haven't already) is: >> > https://developer.android.com/studio/projects/add-native-code.html >> > >> > >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey >> > wrote: >> >> >> >> 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, internally, are CMake build directories managed? Do you >> >> generate 1 per unique android project? What about for each specific >> >> platform (x86, armeabi-v7a, etc)? >> >> 2) Last time I looked into CMake integration, things defined inside >> >> the CMake scripts were ignored because they are specified at the >> >> command line. Namely, all of those settings that are driven by the >> >> Gradle configuration (CXX language level was one in particular I >> >> think; I specify C++14 support via CMake, but I recall this being >> >> overridden from outside)? >> >> 3) How redundant is it to configure individual libraries via the >> >> gradle scripts? In my previous attempts, I wanted to define common >> >> stuff for CMake / native code at the root gradle or settings file, and >> >> only define the differences in the actual gradle build files for each >> >> corresponding Java target (like, defining the name of the native >> >> (shared library) target in Gradle, but the command line invocation, -D >> >> CMake settings, etc would all be common and defined at the root). >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing things and >> >> keep CMake-related settings self-contained to the CMake scripts >> >> themselves, the better. This also makes cross-platform easier (we >> >> build the native code in Windows, for example, so having settings >> >> specified in the gradle files do not carry over to other platforms. >> >> Namely, settings that are not platform specific like the C++ language >> >> level). >> >> >> >> If there's a detailed document / wiki I can read on the intrinsics of >> >> CMake integration in Gradle / Android Studio, I'd love to read it. >> >> Otherwise, I hope you won't mind if I pick your brain as questions >> >> come up. I think I'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 make sure I code my CMake scripts properly for >> >> not only Android, but my other platforms as well (non-Android >> >> platfo
Re: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1
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] >ninja: error: build.ninja:30: loading 'rules.ninja': >指定されたファイルが見つかりません。 Thanks. Is that this issue? https://gitlab.kitware.com/cmake/cmake/issues/17191 Otherwise, please open a new issue. Thanks, -Brad -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
Re: [CMake] CMake + Gradle for Android
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 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 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 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: > > https://developer.android.com/ndk/guides/cmake.html#variables. > > Philosophically, we try to set as little as we can get away with. In > > particular, the section titled "Understanding the CMake build command" > lays > > out exactly what we set. You can also see the folders we specify (one per > > module per ABI) > > 3) Not sure I understand this. > > > > The other document worth taking a look at (if you haven't already) is: > > https://developer.android.com/studio/projects/add-native-code.html > > > > > > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > > wrote: > >> > >> 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, internally, are CMake build directories managed? Do you > >> generate 1 per unique android project? What about for each specific > >> platform (x86, armeabi-v7a, etc)? > >> 2) Last time I looked into CMake integration, things defined inside > >> the CMake scripts were ignored because they are specified at the > >> command line. Namely, all of those settings that are driven by the > >> Gradle configuration (CXX language level was one in particular I > >> think; I specify C++14 support via CMake, but I recall this being > >> overridden from outside)? > >> 3) How redundant is it to configure individual libraries via the > >> gradle scripts? In my previous attempts, I wanted to define common > >> stuff for CMake / native code at the root gradle or settings file, and > >> only define the differences in the actual gradle build files for each > >> corresponding Java target (like, defining the name of the native > >> (shared library) target in Gradle, but the command line invocation, -D > >> CMake settings, etc would all be common and defined at the root). > >> > >> The TLDR is, the closer we can stay to CMake's way of doing things and > >> keep CMake-related settings self-contained to the CMake scripts > >> themselves, the better. This also makes cross-platform easier (we > >> build the native code in Windows, for example, so having settings > >> specified in the gradle files do not carry over to other platforms. > >> Namely, settings that are not platform specific like the C++ language > >> level). > >> > >> If there's a detailed document / wiki I can read on the intrinsics of > >> CMake integration in Gradle / Android Studio, I'd love to read it. > >> Otherwise, I hope you won't mind if I pick your brain as questions > >> come up. I think I'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 make sure I code my CMake 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 > wrote: > >> > 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 older CMake for now then I'd go this > >> > way. > >> > As you mentioned, option (1) will allow you to view your source file > >> > structure in Android Studio, edit files, and debug using the built-in > >> > debugging support. > >> > > >> > To get option (2) to work, you can use jniDirs set
Re: [CMake] CMake + Gradle for Android
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 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 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: > https://developer.android.com/ndk/guides/cmake.html#variables. > Philosophically, we try to set as little as we can get away with. In > particular, the section titled "Understanding the CMake build command" lays > out exactly what we set. You can also see the folders we specify (one per > module per ABI) > 3) Not sure I understand this. > > The other document worth taking a look at (if you haven't already) is: > https://developer.android.com/studio/projects/add-native-code.html > > > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey > wrote: >> >> 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, internally, are CMake build directories managed? Do you >> generate 1 per unique android project? What about for each specific >> platform (x86, armeabi-v7a, etc)? >> 2) Last time I looked into CMake integration, things defined inside >> the CMake scripts were ignored because they are specified at the >> command line. Namely, all of those settings that are driven by the >> Gradle configuration (CXX language level was one in particular I >> think; I specify C++14 support via CMake, but I recall this being >> overridden from outside)? >> 3) How redundant is it to configure individual libraries via the >> gradle scripts? In my previous attempts, I wanted to define common >> stuff for CMake / native code at the root gradle or settings file, and >> only define the differences in the actual gradle build files for each >> corresponding Java target (like, defining the name of the native >> (shared library) target in Gradle, but the command line invocation, -D >> CMake settings, etc would all be common and defined at the root). >> >> The TLDR is, the closer we can stay to CMake's way of doing things and >> keep CMake-related settings self-contained to the CMake scripts >> themselves, the better. This also makes cross-platform easier (we >> build the native code in Windows, for example, so having settings >> specified in the gradle files do not carry over to other platforms. >> Namely, settings that are not platform specific like the C++ language >> level). >> >> If there's a detailed document / wiki I can read on the intrinsics of >> CMake integration in Gradle / Android Studio, I'd love to read it. >> Otherwise, I hope you won't mind if I pick your brain as questions >> come up. I think I'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 make sure I code my CMake 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 wrote: >> > 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 older CMake for now then I'd go this >> > way. >> > As you mentioned, option (1) will allow you to view your source file >> > structure in Android Studio, edit files, and debug using the built-in >> > debugging support. >> > >> > To get option (2) to work, you can use jniDirs setting to tell Android >> > Gradle where to pick up your built .so files (see >> > >> > https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7). >> > I'm not aware of any projects that use this approach but it should work >> > in >> > principal. >> > >> > I hope this helps, >> > Jomo >> > >> > >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey >> > >> > wrote: >> >> >> >> Right now I have custom targets set to e
Re: [CMake] 'cmake.exe -G Ninja' doesn't work for VS2017 with cmake ver 3.9.1
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-690acadc17263621f5361d48057c6f938e698a58 > git revert 690acadc17263621f5361d48057c6f938e698a58 > git bisect log git bisect start # bad: [a1b84ac2a6eec367a8a56f4a0f811e78f5d60fab] CMake Nightly Date Stamp git bisect bad a1b84ac2a6eec367a8a56f4a0f811e78f5d60fab # good: [db3499df5d06ab2cacc61e9f7720a33456aeafe4] CMake 3.7.1 git bisect good db3499df5d06ab2cacc61e9f7720a33456aeafe4 # good: [f36eaf6a6eb8a7ef1127ad43e419896be89f0e39] Refactor WINDOWS_EXPORT_ALL_SYMBOLS implementation git bisect good f36eaf6a6eb8a7ef1127ad43e419896be89f0e39 # good: [80e0ef4082d999e629688e9a6639ac498634b5ed] Merge topic 'GNU-FindBinUtils-patterns' git bisect good 80e0ef4082d999e629688e9a6639ac498634b5ed # bad: [43c3afa74538fd7b78bcf534bfb3fa93c3c1f191] Merge topic 'fix-crash-on-non-enabled-language-features' git bisect bad 43c3afa74538fd7b78bcf534bfb3fa93c3c1f191 # bad: [2d3d88f3bb7076a26d9147f63453931595133aa1] Merge topic 'GoogleTest-disabled-tests' git bisect bad 2d3d88f3bb7076a26d9147f63453931595133aa1 # good: [256481499d56589e98659bd069d7f8a2fd653546] Merge topic 'update-kwsys' git bisect good 256481499d56589e98659bd069d7f8a2fd653546 # bad: [47281310bf610f3ab975d00831e9f3fe713ddde1] Merge topic 'minor-cleanups' git bisect bad 47281310bf610f3ab975d00831e9f3fe713ddde1 # bad: [f8642f953d3d8547bd31fcb35a4737fa91d9126f] Merge topic 'reduce-string-copying' git bisect bad f8642f953d3d8547bd31fcb35a4737fa91d9126f # bad: [bc341a9d5e3863dd80393144eae88f27883db764] Merge topic 'update-libuv' git bisect bad bc341a9d5e3863dd80393144eae88f27883db764 # good: [6f74bbaffec687dce755ee985b3bf69e915d3a8d] Merge topic 'findxmlrpc_fix' git bisect good 6f74bbaffec687dce755ee985b3bf69e915d3a8d # bad: [1ebb421bfc8eb21a4e5e56e501a62d000a9f59db] Merge branch 'upstream-libuv' into update-libuv git bisect bad 1ebb421bfc8eb21a4e5e56e501a62d000a9f59db # bad: [bc407ba6ba28293b5fc0025fa08e8fe71365eab8] Merge topic 'codecvt-revise' git bisect bad bc407ba6ba28293b5fc0025fa08e8fe71365eab8 # bad: [690acadc17263621f5361d48057c6f938e698a58] codecvt: Re-implement do_out and do_unshift git bisect bad 690acadc17263621f5361d48057c6f938e698a58 # first bad commit: [690acadc17263621f5361d48057c6f938e698a58] codecvt: Re-implement do_out and do_unshift This is the batch file which was used for 'git bisect'. I used https://github.com/m-tmatma/cmake-sample.git as the input of cmake. -- @echo on cd /d %~dp0 set CONFIGURATION=Debug set SRC_CMAKE=%~dp0 set SRC_HELLO=%~dp0..\cmake-sample\HelloWorld set OUTDIR_CMAKE=%~dp0build-cmake set OUTDIR_HELLO=%~dp0build-hello set BUILT_CMAKE=%OUTDIR_CMAKE%\bin\%CONFIGURATION%\cmake.exe set DEVENV="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.com" if not exist %OUTDIR_CMAKE% mkdir %OUTDIR_CMAKE% cd /d %OUTDIR_CMAKE% cmake -G "Visual Studio 15 2017" -D CMAKE_INSTALL_PREFIX=c:\cmake %SRC_CMAKE% %DEVENV% CMake.sln /build "%CONFIGURATION%|Win32" /project cmake cd /d %~dp0 if not exist %OUTDIR_HELLO% mkdir %SRC_HELLO% cd /d %OUTDIR_HELLO% %BUILT_CMAKE% -G Ninja %SRC_HELLO% || ( echo error && cd /d %~dp0 && exit /b 1) cd /d %~dp0 exit /b 0 -- Masaru Tsuchiyama wrote: Hello I found a bug that cmake doesn't create 'rules.ninja' while the build process even though generated build.ninja has a line "include rules.ninja". Then running with -G Ninja fails with VS2017. cmake ver 3.7.1 doesn't happen . cmake ver 3.9.1 happens. cmake bb3647060cd8ddc4184687b64469d6a8554f49b3 happens. I found this for llvm first, but it happens with the other projects. example: HelloWorld in https://github.com/m-tmatma/cmake-sample.git HelloWorld is a very simple cmake project. This commands can reproduce this. git clone https://github.com/m-tmatma/cmake-sample.git mkdir cmake-sample\HelloWorld\Build cdcmake-sample\HelloWorld\Build call "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" x86 cmake.exe -G Ninja .. This is the output of cmake bb3647060cd8ddc4184687b64469d6a8554f49b3. --- -- The C compiler identification is MSVC 19.11.25506.0 -- The CXX compiler identification is MSVC 19.11.25506.0 -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.11.25503/bin/HostX86/x86/cl.exe -- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/
[CMake] two llvm libraries.
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 '../build/MyCFGPass/libMyCFGPass.so': ../build/MyCFGPass/libMyCFGPass.so: undefined symbol: _ZTVN8bitwidth16OptimizeBitwidthE - one pass does not see another at all. I can't link this library because it is MODULE but I also can't create a second static library as in this case the pass will try to register itself twice )(in .a and .so files). What can be the problem that I can't use one class inside another and what can be a solution to this? I have: passA.cpp <- includes "passB.h", passB.h, passB.cpp, I want to have passA.so, passB.so, passA uses the analysis from passB. Does the fact that I defined passB under namespace influence the problem? -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake
