Re: [CMake] CMake + Gradle for Android
>>>> >> >> 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 >>> >> >> >>>>> >> >> <jomofis...@gmail.com> >>> >> >> >>>>> >> >> 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 >>> >> >> >>>>> >>
Re: [CMake] CMake + Gradle for Android
> 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 >> >> >> >>>>> >> >> > <rcdailey.li...@gmail.com> >> >> >> >>>>> >> >> > 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 >> >> >> >>>>> >> >> >> <jomofis...@gmail.com> >> >> >> >>>>> >> >> >> wrote: >> >> >> >>>>> >> >> >> > Gradle does introspection on
Re: [CMake] CMake + Gradle for Android
e > >> >> >>>>> >> >> 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 > >> >> >>>>> >> >> <jomofis...@gmail.com> > >> >> >>>>> >> >> 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 > >> >> >>>>> >> >> > <rcdailey.li...@gmail.com> > >> >> >>>>> >> >> > 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 > >> >> >>>>> >> >&g
Re: [CMake] CMake + Gradle for Android
t;> >>>>> >> >> > 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 >> >> >>>>> >> >> > <rcdailey.li...@gmail.com> >> >> >>>>> >> >> > 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 >> >> >>>>> >> >> >> <jomofis...@gmail.com> >> >> >>>>> >> >> >> 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 >> >> >>>>> >> >>
Re: [CMake] CMake + Gradle for Android
;>> >> >> 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 >> >> >>>>> >> >> <jomofis...@gmail.com> >> >> >>>>> >> >> 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 >> >> >>>>> >> >> > <rcdailey.li...@gmail.com> >> >> >>>>> >> >> > 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 & >> >> >>>>
Re: [CMake] CMake + Gradle for Android
On Thu, Aug 24, 2017 at 5:20 AM, Jom O'Fisherwrote: > 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 builds. > In case it's helpful, the following article discusses how to set up a project for ccache without having to assume ccache has been installed with symlinks, etc. to replace the default compiler: https://crascit.com/2016/04/09/using-ccache-with-cmake/ This approach has saved us a huge amount of time in our builds, including some fairly complex hierarchical projects. -- Craig Scott Melbourne, Australia https://crascit.com -- 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
t;> >> > >> >>>>> >> >> 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 > >> >>>>> >> >> <jomofis...@gmail.com> > >> >>>>> >> >> 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 > >> >>>>> >> >> > <rcdailey.li...@gmail.com> > >> >>>>> >> >> > 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 > >> >>>>> >>
Re: [CMake] CMake + Gradle for Android
aged. >> >>>>> >> >> >> >> >>>>> >> >> >> 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 >> >>>>> >> >> >> <jomofis...@gmail.com> >> >>>>> >> >> >> 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 >> >>>>> >> >> >> > <rcdailey.li...@gmail.com> >> >>>>> >> >> >> > 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 >> >>>>> >> >> >> >> <jomofis...@gmail.com> >> >>>>> >> >> >> >> wrote: >> >&g
Re: [CMake] CMake + Gradle for Android
> > 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 > >>>>> >> >> > <rcdailey.li...@gmail.com> > >>>>> >> >> > 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 > >>>>> >> >> >> <jomofis...@gmail.com> > >>>>> >> >> >> 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 > >>>>> >> >> >> > <rcdailey.li...@gmail.com> > >>>>> >> >> >> > 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 &
Re: [CMake] CMake + Gradle for Android
gt; >> 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 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 >>>>> >> >> >> > <rcdailey.li...@gmail.com> >>>>> >> >> >> > 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 >>>>> >> >> >> >> <jomofis...@gmail.com> >>>>> >> >> >> >> 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
Re: [CMake] CMake + Gradle for Android
nder "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 >>>> >> >> >> >> <jomofis...@gmail.com> >>>> >> >> >> >> 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 >>>> >> >> >&
Re: [CMake] CMake + Gradle for Android
gt; >> >> 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 >>>> >> >> >> >> <jomofis...@gmail.com> >>>> >> >> >> >> 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 >>>> >> >> >> >> >&
Re: [CMake] CMake + Gradle for Android
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 >> >> >> >> > <rcdailey.li...@gmail.com> >> >> >> >> > 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 >> >> >> >> >> <jomofis...@gmail.com> >> >> >> >> >> 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 >&g
Re: [CMake] CMake + Gradle for Android
o 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 > >> >> >> >> <jomofis...@gmail.com> > >> >> >> >> 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 in
Re: [CMake] CMake + Gradle for Android
;> >> >> > 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 >> >> >> >> >
Re: [CMake] CMake + Gradle for Android
ecause 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 > >> >>
Re: [CMake] CMake + Gradle for Android
hould 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 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 >> >> > <rcdailey.li...@gmail.com> >> >> > 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 <jomofis...@gmail.com> >> >> >> 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
Re: [CMake] CMake + Gradle for Android
mail.com> > >> >> 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 integration in Gradle / Android Studio, I'd love to read it. > >> >> >> Otherwise, I hope
Re: [CMake] CMake + Gradle for Android
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 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 <jomofis...@gmail.com> >> >> >> wrote: >> >> >> > Either option can work fine. Disclosure: I work on Android Studio >> >> >> > and >> >> >> > was >> >> >> > the one that
Re: [CMake] CMake + Gradle for Android
r 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 <jomofis...@gmail.com> > >> >> 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 > >> >> > <rcdailey.li...@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> 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 means using Android Studio and being > >> >> >> locked down to Google's fork of CMake which is a few major > releases > >> >> >> behind. I see that as a negative. > >> >> >> > >> >> >> 2. CMake drives Gradle: This would be the same or similar to what > >> >> >> I'm > >> >> >> already doing: The custom targets I have would execute gradle as a > >> >> >> separate build step, instead of running ant commands. I'm not too > >> >> >> familiar with Gradle, so I'm not sure how you tell it where your > >> >> >> shared libraries are for the APK packaging steps. > >> >> >> > >> >> >> Which does everyone recommend? Is anyone using one of these setups > >> >> >> successfully? The downside to option 2 is probably no on-device > >> >> >> native > >> >> >> debugging since Android Studio probably can't handle gradle > projects > >> >> >> without any external CMake builds set up. > >> >> >> > >> >> >> Would like some general direction & advice before I move away from > >> >> >> ANT. Thanks in advance. > >> >> >> -- > >> >> >> > >> >> >> 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 > >> >> > > >> >> > > >> > > >> > > > > > > -- 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
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 <jomofis...@gmail.com> 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 <rcdailey.li...@gmail.com> > 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 <jomofis...@gmail.com> 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
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 <rcdailey.li...@gmail.com> 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 <jomofis...@gmail.com> 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 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
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 <jomofis...@gmail.com> 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 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 <jomofis...@gmail.com> 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 bui
Re: [CMake] CMake + Gradle for Android
On 8/8/17, Jom O'Fisherwrote: > 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 let > you set a file path in local.properties and/or specify a CMake version > number in build.gradle where we'd search for it in some well-known > locations. I think I could live with local.properties. Any chance you could fast track this and get it in soon? Somewhat coincidentally, my fork of CMake happened close to the time of where the Google fork seemed to happen. I tried the merge. I got tons of conflicts for other things, not my changes. I'm about half-way resolving them...but my changeset is relatively small so I've been thinking I might just manually repatch on yours or try the cherry-picking feature of Git. Thanks, Eric -- 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
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 let you set a file path in local.properties and/or specify a CMake version number in build.gradle where we'd search for it in some well-known locations. On Tue, Aug 8, 2017 at 5:21 PM, Eric Wingwrote: > 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 CMake > while they wait (perhaps they could have merged with Google's branch > manually) > > 2) In my case, I'm trying to implement new features into CMake (Swift > compiler support). It's not going to be mainlined anytime soon since > it is a long project, so even when you catch up, I still need to be > able to call my fork of CMake. > > I don't want to overwrite anything in the Android distribution, and I > have people using my stuff and helping me, so we need a way to > collaborate. A simple gradle argument that lets me specify an > alternative path to CMake would fix my problem. (The other things I > need are specifying a toolchain file which I think you already support > and an Initial Cache (-C switch) which maybe is implicitly supported > since it is just a generic CMake command line argument. > > > Right now, I am doing the alternative method of calling CMake myself > through Gradle/Groovy scripts as people used to do. But I never > figured out how to get debugger integration with Android Studio as a > consequence. I would really like to move to the official Google/CMake > support, but I can't do that unless I can invoke a different CMake. (I > did pull the Google fork of CMake and I think my changes are > mergable.) > > Thanks, > Eric > -- 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
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 CMake while they wait (perhaps they could have merged with Google's branch manually) 2) In my case, I'm trying to implement new features into CMake (Swift compiler support). It's not going to be mainlined anytime soon since it is a long project, so even when you catch up, I still need to be able to call my fork of CMake. I don't want to overwrite anything in the Android distribution, and I have people using my stuff and helping me, so we need a way to collaborate. A simple gradle argument that lets me specify an alternative path to CMake would fix my problem. (The other things I need are specifying a toolchain file which I think you already support and an Initial Cache (-C switch) which maybe is implicitly supported since it is just a generic CMake command line argument. Right now, I am doing the alternative method of calling CMake myself through Gradle/Groovy scripts as people used to do. But I never figured out how to get debugger integration with Android Studio as a consequence. I would really like to move to the official Google/CMake support, but I can't do that unless I can invoke a different CMake. (I did pull the Google fork of CMake and I think my changes are mergable.) Thanks, Eric -- 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
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 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 <jomofis...@gmail.com> 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 <rcdailey.li...@gmail.com > > > > wrote: > >> > >> 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
Re: [CMake] CMake + Gradle for Android
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 <jomofis...@gmail.com> 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 <rcdailey.li...@gmail.com> > wrote: >> >> 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 means using Android Studio and being >> locked down to Google's fork of CMake which is a few major releases >> behind. I see that as a negative. >> >> 2. CMake drives Gradle: This would be the same or similar to what I'm >> already doing: The custom targets I have would execute gradle as a >> separate build step, instead of running ant commands. I'm not too >> familiar with Gradle, so I'm not sure how you tell it where your >> shared libraries are for the APK packaging steps. >> >> Which does everyone recommend? Is anyone using one of these setups >> successfully? The downside to option 2 is probably no on-device native >> debugging since Android Studio probably can't handle gradle projects >> without any external CMake builds set up. >> >> Would like some general direction & advice before I move away from >> ANT. Thanks in advance. >> -- >> >> Powered by www.kitware.com >> >> Please keep messages on-topic and check the CMake FAQ at: >> http://www.cmake.org/Wiki/CMake_FAQ >> >>
Re: [CMake] CMake + Gradle for Android
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 Daileywrote: > 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 means using Android Studio and being > locked down to Google's fork of CMake which is a few major releases > behind. I see that as a negative. > > 2. CMake drives Gradle: This would be the same or similar to what I'm > already doing: The custom targets I have would execute gradle as a > separate build step, instead of running ant commands. I'm not too > familiar with Gradle, so I'm not sure how you tell it where your > shared libraries are for the APK packaging steps. > > Which does everyone recommend? Is anyone using one of these setups > successfully? The downside to option 2 is probably no on-device native > debugging since Android Studio probably can't handle gradle projects > without any external CMake builds set up. > > Would like some general direction & advice before I move away from > ANT. Thanks in advance. > -- > > 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 > -- 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
[CMake] CMake + Gradle for Android
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 means using Android Studio and being locked down to Google's fork of CMake which is a few major releases behind. I see that as a negative. 2. CMake drives Gradle: This would be the same or similar to what I'm already doing: The custom targets I have would execute gradle as a separate build step, instead of running ant commands. I'm not too familiar with Gradle, so I'm not sure how you tell it where your shared libraries are for the APK packaging steps. Which does everyone recommend? Is anyone using one of these setups successfully? The downside to option 2 is probably no on-device native debugging since Android Studio probably can't handle gradle projects without any external CMake builds set up. Would like some general direction & advice before I move away from ANT. Thanks in advance. -- 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