<div dir="ltr">+ a colleague </div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 21, 2017 at 3:11 PM, Jom O'Fisher <span dir="ltr"><<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You can find that number like this:<div>- x = number of externalNativeBuild.cmake.path in your build.gradle files</div><div>- y = number of gradle configurations (like debug and release)</div><div>- z = number of ABIs that you build</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Hope this helps.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 21, 2017 at 2:41 PM, Robert Dailey <span dir="ltr"><<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This definitely a bit better, but still requires the boilerplate in<br>
each leaf gradle file. But I can't seriously complain too much. I<br>
think I'm more concerned with the implications this has underneath.<br>
First, let me ask just to make sure I'm not misunderstanding: Does<br>
each `externalNativeBuild` entry essentially mean 1 CMAKE_BINARY_DIR?<br>
How many binary dirs do you manage internally and what determines when<br>
they get created?<br>
<div class="m_-3505621477745602038HOEnZb"><div class="m_-3505621477745602038h5"><br>
On Mon, Aug 21, 2017 at 2:35 PM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>> wrote:<br>
> Would it work for your scenario to provide properties in the root<br>
> build.gradle:<br>
><br>
> ext {<br>
> cmakePath = file "CMakeLists.txt"<br>
> }<br>
><br>
> And then consume them in the leaf app/build.gradle like this?<br>
><br>
> externalNativeBuild {<br>
> cmake {<br>
> path cmakePath<br>
> }<br>
> }<br>
><br>
> It doesn't fully hide the details but it does centralize the information.<br>
><br>
><br>
> On Mon, Aug 21, 2017 at 11:20 AM, Robert Dailey <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
> wrote:<br>
>><br>
>> I wouldn't want to do that, it's too convoluted. I have other<br>
>> platforms that use these CMake scripts as well. For example, I run on<br>
>> Windows and Linux platforms as well to build the native code. Normal<br>
>> CMake behavior is designed to work at a root then go downwards to find<br>
>> targets. However it seems Gradle wants to start at a subdirectory and<br>
>> work its way up to the root, which is opposite of CMake's intended<br>
>> behavior IMHO. Not only that but I want to avoid special-casing<br>
>> behavior in CMake just for Android's use.<br>
>><br>
>> At the moment it feels like (again referring back to my previous<br>
>> example structure) that both App2 and App3 each run CMake in<br>
>> independent binary directories instead of sharing 1 binary directory<br>
>> and building 2 targets inside of it. I prefer this behavior instead,<br>
>> especially since it allows CMake to operate as it was intended. I<br>
>> think it's a common case that projects will define multiple targets<br>
>> starting from a single root, and expect multiple APKs or java<br>
>> dependencies to be built within it.<br>
>><br>
>> If I'm misunderstanding or making false assumptions please let me know.<br>
>><br>
>><br>
>><br>
>> On Mon, Aug 21, 2017 at 12:00 PM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>><br>
>> wrote:<br>
>> > Would it work for your situation for the leaf CMakeLists.txt to include<br>
>> > the<br>
>> > root CMakeLists.txt? Then have the leaf-specific logic in the leaf<br>
>> > CMakeLists.txt?<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Aug 21, 2017 at 9:33 AM, Robert Dailey<br>
>> > <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Basically, yes. We have this sort of structure:<br>
>> >><br>
>> >> <Root of git clone>/<br>
>> >> Applications/<br>
>> >> App1/<br>
>> >> build.gradle<br>
>> >> CMakeLists.txt<br>
>> >> App2/<br>
>> >> build.gradle<br>
>> >> CMakeLists.txt<br>
>> >> App3/<br>
>> >> build.gradle<br>
>> >> CMakeLists.txt<br>
>> >> CommonLib/<br>
>> >> build.gradle<br>
>> >> CMakeLists.txt<br>
>> >> CMakeLists.txt<br>
>> >><br>
>> >> The libs are defined as follows:<br>
>> >><br>
>> >> * CommonLib is a static library (java code builds into a library)<br>
>> >> * No dependencies of its own<br>
>> >> * App1 is a shared library (java code builds into a library)<br>
>> >> * Dependencies (both java & native): CommonLib<br>
>> >> * App2 is a shared library (java code builds into an APK)<br>
>> >> * Dependencies (both java & native): App1, CommonLib<br>
>> >> * App3 is a shared library (java code builds into an APK)<br>
>> >> * Dependencies (both java & native): CommonLib<br>
>> >><br>
>> >> In all cases, CMake must be invoked starting at the root<br>
>> >> CMakeLists.txt 1 time. Each target can be built from the same binary<br>
>> >> directory after that. Previously with ANT, I was building all native<br>
>> >> targets first, then moved libs to appropriate directories so that the<br>
>> >> 'ant' command would package the libs.<br>
>> >><br>
>> >> For gradle, I wanted to avoid redundantly specifying the root<br>
>> >> directory in each leaf-level project directory. Using the example<br>
>> >> above, the leaf-level directories in this case would be App1, App2,<br>
>> >> App3, and CommonLib. However I think we only specify the native CMake<br>
>> >> stuff for the java targets that actually output an APK (that would be<br>
>> >> App2 and App3 only).<br>
>> >><br>
>> >> The ultimate goal is to specify stuff that doesn't change per<br>
>> >> independent "module" of ours at the top level so it is transitive /<br>
>> >> inherited. Then only specify the differences (e.g. the native CMake<br>
>> >> target to build) in the leaf build gradle files. However you indicated<br>
>> >> this isn't possible.<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Mon, Aug 21, 2017 at 11:11 AM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>><br>
>> >> wrote:<br>
>> >> > What you're doing already sounds correct. You can't directly specify<br>
>> >> > CMakeLists.txt from the top-level build.gradle. Recommendation is<br>
>> >> > that<br>
>> >> > it<br>
>> >> > should be specified from the build.gradle of the module of the APK.<br>
>> >> > Is<br>
>> >> > the<br>
>> >> > issue that you have multiple APK modules that all reference the same<br>
>> >> > CMake<br>
>> >> > libraries?<br>
>> >> ><br>
>> >> > On Mon, Aug 21, 2017 at 9:00 AM, Robert Dailey<br>
>> >> > <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
>> >> > wrote:<br>
>> >> >><br>
>> >> >> Thanks this is very helpful. The other question I have is: Is there<br>
>> >> >> a<br>
>> >> >> place to centrally specify the root CMakeLists.txt? Basically, I<br>
>> >> >> want<br>
>> >> >> to specify the CMake root in 1 place, and have targets (defined<br>
>> >> >> further down in subdirectories) that require APK packaging to<br>
>> >> >> specify<br>
>> >> >> only the native target name that should be built & packaged.<br>
>> >> >><br>
>> >> >> At the moment we specify the root CMakeLists.txt by walking up the<br>
>> >> >> tree, paths like "../../../../CMakeLists.txt". I think this should<br>
>> >> >> be<br>
>> >> >> put at the top-level build gradle file if possible. Is this doable<br>
>> >> >> at<br>
>> >> >> the moment? What is the recommended setup?<br>
>> >> >><br>
>> >> >> On Mon, Aug 21, 2017 at 9:37 AM, Jom O'Fisher <<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>><br>
>> >> >> wrote:<br>
>> >> >> > Gradle does introspection on the CMake build to find .so targets<br>
>> >> >> > and<br>
>> >> >> > those<br>
>> >> >> > get packaged.<br>
>> >> >> > There is also a special case for stl/runtime .so files from the<br>
>> >> >> > NDK.<br>
>> >> >> > Any additional .so files need to specified in build.gradle using<br>
>> >> >> > jniDirs<br>
>> >> >> ><br>
>> >> >> > On Mon, Aug 21, 2017 at 7:30 AM, Robert Dailey<br>
>> >> >> > <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
>> >> >> > wrote:<br>
>> >> >> >><br>
>> >> >> >> How exactly does Gradle package *.so files in an APK? I know that<br>
>> >> >> >> ANT<br>
>> >> >> >> used to do this for any libs under "libs/<ABI>". Does Gradle do<br>
>> >> >> >> some<br>
>> >> >> >> introspection into CMake targets to see if outputs are *.so, and<br>
>> >> >> >> copy<br>
>> >> >> >> those to some location if needed? What about libraries like<br>
>> >> >> >> libgnustl_shared.so that come with the NDK? I'd like to know if<br>
>> >> >> >> any<br>
>> >> >> >> manual copy steps are needed in CMake to put outputs in proper<br>
>> >> >> >> locations for the APK build step. I had to do this when using<br>
>> >> >> >> ANT.<br>
>> >> >> >><br>
>> >> >> >> On Mon, Aug 7, 2017 at 6:16 PM, Jom O'Fisher<br>
>> >> >> >> <<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>><br>
>> >> >> >> wrote:<br>
>> >> >> >> > 1) There is a folder created for each ABI under the project<br>
>> >> >> >> > module<br>
>> >> >> >> > folder<br>
>> >> >> >> > (so unique per module per ABI)<br>
>> >> >> >> > 2) Gradle doesn't specify language level though you can choose<br>
>> >> >> >> > to<br>
>> >> >> >> > specify it<br>
>> >> >> >> > yourself from the build.gradle. This doc does a pretty good job<br>
>> >> >> >> > of<br>
>> >> >> >> > explaining which variables are set by Gradle:<br>
>> >> >> >> > <a href="https://developer.android.com/ndk/guides/cmake.html#variables" rel="noreferrer" target="_blank">https://developer.android.com/<wbr>ndk/guides/cmake.html#variable<wbr>s</a>.<br>
>> >> >> >> > Philosophically, we try to set as little as we can get away<br>
>> >> >> >> > with.<br>
>> >> >> >> > In<br>
>> >> >> >> > particular, the section titled "Understanding the CMake build<br>
>> >> >> >> > command"<br>
>> >> >> >> > lays<br>
>> >> >> >> > out exactly what we set. You can also see the folders we<br>
>> >> >> >> > specify<br>
>> >> >> >> > (one<br>
>> >> >> >> > per<br>
>> >> >> >> > module per ABI)<br>
>> >> >> >> > 3) Not sure I understand this.<br>
>> >> >> >> ><br>
>> >> >> >> > The other document worth taking a look at (if you haven't<br>
>> >> >> >> > already)<br>
>> >> >> >> > is:<br>
>> >> >> >> ><br>
>> >> >> >> > <a href="https://developer.android.com/studio/projects/add-native-code.html" rel="noreferrer" target="_blank">https://developer.android.com/<wbr>studio/projects/add-native-cod<wbr>e.html</a><br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> > On Mon, Aug 7, 2017 at 3:35 PM, Robert Dailey<br>
>> >> >> >> > <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
>> >> >> >> > wrote:<br>
>> >> >> >> >><br>
>> >> >> >> >> Thanks Jom<br>
>> >> >> >> >><br>
>> >> >> >> >> Honestly, I prefer option 1 to work simply because that's how<br>
>> >> >> >> >> Google's<br>
>> >> >> >> >> officially supporting CMake. But it also has debugging which<br>
>> >> >> >> >> is<br>
>> >> >> >> >> the<br>
>> >> >> >> >> #1<br>
>> >> >> >> >> reason for me.<br>
>> >> >> >> >><br>
>> >> >> >> >> However, I'd like to understand a lot more about how the<br>
>> >> >> >> >> integration<br>
>> >> >> >> >> really happens. For example, I have these questions:<br>
>> >> >> >> >><br>
>> >> >> >> >> 1) How, internally, are CMake build directories managed? Do<br>
>> >> >> >> >> you<br>
>> >> >> >> >> generate 1 per unique android project? What about for each<br>
>> >> >> >> >> specific<br>
>> >> >> >> >> platform (x86, armeabi-v7a, etc)?<br>
>> >> >> >> >> 2) Last time I looked into CMake integration, things defined<br>
>> >> >> >> >> inside<br>
>> >> >> >> >> the CMake scripts were ignored because they are specified at<br>
>> >> >> >> >> the<br>
>> >> >> >> >> command line. Namely, all of those settings that are driven by<br>
>> >> >> >> >> the<br>
>> >> >> >> >> Gradle configuration (CXX language level was one in particular<br>
>> >> >> >> >> I<br>
>> >> >> >> >> think; I specify C++14 support via CMake, but I recall this<br>
>> >> >> >> >> being<br>
>> >> >> >> >> overridden from outside)?<br>
>> >> >> >> >> 3) How redundant is it to configure individual libraries via<br>
>> >> >> >> >> the<br>
>> >> >> >> >> gradle scripts? In my previous attempts, I wanted to define<br>
>> >> >> >> >> common<br>
>> >> >> >> >> stuff for CMake / native code at the root gradle or settings<br>
>> >> >> >> >> file,<br>
>> >> >> >> >> and<br>
>> >> >> >> >> only define the differences in the actual gradle build files<br>
>> >> >> >> >> for<br>
>> >> >> >> >> each<br>
>> >> >> >> >> corresponding Java target (like, defining the name of the<br>
>> >> >> >> >> native<br>
>> >> >> >> >> (shared library) target in Gradle, but the command line<br>
>> >> >> >> >> invocation,<br>
>> >> >> >> >> -D<br>
>> >> >> >> >> CMake settings, etc would all be common and defined at the<br>
>> >> >> >> >> root).<br>
>> >> >> >> >><br>
>> >> >> >> >> The TLDR is, the closer we can stay to CMake's way of doing<br>
>> >> >> >> >> things<br>
>> >> >> >> >> and<br>
>> >> >> >> >> keep CMake-related settings self-contained to the CMake<br>
>> >> >> >> >> scripts<br>
>> >> >> >> >> themselves, the better. This also makes cross-platform easier<br>
>> >> >> >> >> (we<br>
>> >> >> >> >> build the native code in Windows, for example, so having<br>
>> >> >> >> >> settings<br>
>> >> >> >> >> specified in the gradle files do not carry over to other<br>
>> >> >> >> >> platforms.<br>
>> >> >> >> >> Namely, settings that are not platform specific like the C++<br>
>> >> >> >> >> language<br>
>> >> >> >> >> level).<br>
>> >> >> >> >><br>
>> >> >> >> >> If there's a detailed document / wiki I can read on the<br>
>> >> >> >> >> intrinsics<br>
>> >> >> >> >> of<br>
>> >> >> >> >> CMake integration in Gradle / Android Studio, I'd love to read<br>
>> >> >> >> >> it.<br>
>> >> >> >> >> Otherwise, I hope you won't mind if I pick your brain as<br>
>> >> >> >> >> questions<br>
>> >> >> >> >> come up. I think I'm going to try option 1 for now and see how<br>
>> >> >> >> >> it<br>
>> >> >> >> >> goes. It's just black box for me because unlike option 2, I<br>
>> >> >> >> >> have<br>
>> >> >> >> >> very<br>
>> >> >> >> >> little control over what happens after building the shared<br>
>> >> >> >> >> libraries,<br>
>> >> >> >> >> and to make up for that I need to really get a deep<br>
>> >> >> >> >> understanding<br>
>> >> >> >> >> of<br>
>> >> >> >> >> how it works so I can make sure I code my CMake scripts<br>
>> >> >> >> >> properly<br>
>> >> >> >> >> for<br>
>> >> >> >> >> not only Android, but my other platforms as well (non-Android<br>
>> >> >> >> >> platforms).<br>
>> >> >> >> >><br>
>> >> >> >> >> Thanks again.<br>
>> >> >> >> >><br>
>> >> >> >> >> On Mon, Aug 7, 2017 at 5:12 PM, Jom O'Fisher<br>
>> >> >> >> >> <<a href="mailto:jomofisher@gmail.com" target="_blank">jomofisher@gmail.com</a>><br>
>> >> >> >> >> wrote:<br>
>> >> >> >> >> > Either option can work fine. Disclosure: I work on Android<br>
>> >> >> >> >> > Studio<br>
>> >> >> >> >> > and<br>
>> >> >> >> >> > was<br>
>> >> >> >> >> > the one that added CMake support.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > Option (1) is the way it's designed to work and we're<br>
>> >> >> >> >> > working<br>
>> >> >> >> >> > toward<br>
>> >> >> >> >> > getting<br>
>> >> >> >> >> > rid of the need for the CMake fork. I can't really say when<br>
>> >> >> >> >> > that<br>
>> >> >> >> >> > will<br>
>> >> >> >> >> > happen<br>
>> >> >> >> >> > but if you can get away with an older CMake for now then I'd<br>
>> >> >> >> >> > go<br>
>> >> >> >> >> > this<br>
>> >> >> >> >> > way.<br>
>> >> >> >> >> > As you mentioned, option (1) will allow you to view your<br>
>> >> >> >> >> > source<br>
>> >> >> >> >> > file<br>
>> >> >> >> >> > structure in Android Studio, edit files, and debug using the<br>
>> >> >> >> >> > built-in<br>
>> >> >> >> >> > debugging support.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > To get option (2) to work, you can use jniDirs setting to<br>
>> >> >> >> >> > tell<br>
>> >> >> >> >> > Android<br>
>> >> >> >> >> > Gradle where to pick up your built .so files (see<br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> > <a href="https://stackoverflow.com/questions/21255125/how-can-i-add-so-files-to-an-android-library-project-using-gradle-0-7" rel="noreferrer" target="_blank">https://stackoverflow.com/ques<wbr>tions/21255125/how-can-i-add-<wbr>so-files-to-an-android-library<wbr>-project-using-gradle-0-7</a>).<br>
>> >> >> >> >> > I'm not aware of any projects that use this approach but it<br>
>> >> >> >> >> > should<br>
>> >> >> >> >> > work<br>
>> >> >> >> >> > in<br>
>> >> >> >> >> > principal.<br>
>> >> >> >> >> ><br>
>> >> >> >> >> > I hope this helps,<br>
>> >> >> >> >> > Jomo<br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> >> > On Mon, Aug 7, 2017 at 11:09 AM, Robert Dailey<br>
>> >> >> >> >> > <<a href="mailto:rcdailey.lists@gmail.com" target="_blank">rcdailey.lists@gmail.com</a>><br>
>> >> >> >> >> > wrote:<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Right now I have custom targets set to execute the "ant<br>
>> >> >> >> >> >> release"<br>
>> >> >> >> >> >> command after my native targets are built. Part of that<br>
>> >> >> >> >> >> command<br>
>> >> >> >> >> >> involves copying *.so files to the libs/armeabi-v7a<br>
>> >> >> >> >> >> directory<br>
>> >> >> >> >> >> so<br>
>> >> >> >> >> >> they<br>
>> >> >> >> >> >> get packaged in an APK.<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> When switching to gradle, I have two options:<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> 1. Gradle drives CMake: This means using Android Studio and<br>
>> >> >> >> >> >> being<br>
>> >> >> >> >> >> locked down to Google's fork of CMake which is a few major<br>
>> >> >> >> >> >> releases<br>
>> >> >> >> >> >> behind. I see that as a negative.<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> 2. CMake drives Gradle: This would be the same or similar<br>
>> >> >> >> >> >> to<br>
>> >> >> >> >> >> what<br>
>> >> >> >> >> >> I'm<br>
>> >> >> >> >> >> already doing: The custom targets I have would execute<br>
>> >> >> >> >> >> gradle<br>
>> >> >> >> >> >> as<br>
>> >> >> >> >> >> a<br>
>> >> >> >> >> >> separate build step, instead of running ant commands. I'm<br>
>> >> >> >> >> >> not<br>
>> >> >> >> >> >> too<br>
>> >> >> >> >> >> familiar with Gradle, so I'm not sure how you tell it where<br>
>> >> >> >> >> >> your<br>
>> >> >> >> >> >> shared libraries are for the APK packaging steps.<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Which does everyone recommend? Is anyone using one of these<br>
>> >> >> >> >> >> setups<br>
>> >> >> >> >> >> successfully? The downside to option 2 is probably no<br>
>> >> >> >> >> >> on-device<br>
>> >> >> >> >> >> native<br>
>> >> >> >> >> >> debugging since Android Studio probably can't handle gradle<br>
>> >> >> >> >> >> projects<br>
>> >> >> >> >> >> without any external CMake builds set up.<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Would like some general direction & advice before I move<br>
>> >> >> >> >> >> away<br>
>> >> >> >> >> >> from<br>
>> >> >> >> >> >> ANT. Thanks in advance.<br>
>> >> >> >> >> >> --<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Please keep messages on-topic and check the CMake FAQ at:<br>
>> >> >> >> >> >> <a href="http://www.cmake.org/Wiki/CMake_FAQ" rel="noreferrer" target="_blank">http://www.cmake.org/Wiki/CMak<wbr>e_FAQ</a><br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Kitware offers various services to support the CMake<br>
>> >> >> >> >> >> community.<br>
>> >> >> >> >> >> For<br>
>> >> >> >> >> >> more<br>
>> >> >> >> >> >> information on each offering, please visit:<br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> CMake Support: <a href="http://cmake.org/cmake/help/support.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/su<wbr>pport.html</a><br>
>> >> >> >> >> >> CMake Consulting:<br>
>> >> >> >> >> >> <a href="http://cmake.org/cmake/help/consulting.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/co<wbr>nsulting.html</a><br>
>> >> >> >> >> >> CMake Training Courses:<br>
>> >> >> >> >> >> <a href="http://cmake.org/cmake/help/training.html" rel="noreferrer" target="_blank">http://cmake.org/cmake/help/tr<wbr>aining.html</a><br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Visit other Kitware open-source projects at<br>
>> >> >> >> >> >> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensou<wbr>rce/opensource.html</a><br>
>> >> >> >> >> >><br>
>> >> >> >> >> >> Follow this link to subscribe/unsubscribe:<br>
>> >> >> >> >> >> <a href="http://public.kitware.com/mailman/listinfo/cmake" rel="noreferrer" target="_blank">http://public.kitware.com/mail<wbr>man/listinfo/cmake</a><br>
>> >> >> >> >> ><br>
>> >> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> >> ><br>
>> >> >> ><br>
>> >> >> ><br>
>> >> ><br>
>> >> ><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>