Use explicit host build strategy for cross compiling HANNK

[alexreinking]

There's a bunch of changes in here, and I thought it would be better to review them here, rather than just pushing to your branch. I took some care to make each commit self-contained and easy to interpret. The big changes are in the last two:

First, the cross-compiling strategy changed significantly. Rather than shelling out via execute_process and potentially guessing the toolchain options wrong, expect to find our host tools (i.e. generators) in a package called "hannk_tools".

The package is created by the host build via the CMake export() command. Importing this package in the cross build creates IMPORTED targets with the same names as our generators. We then use these generators rather than creating generators for the target build.

Second, the configure_cmake.sh script now takes charge of creating a host build when cross compiling for Android or WASM.

Oh yeah, Android NDK cross compiling works now, too!

Overall, the code for this is much smaller and more robust to unknown environments.

[steven-johnson]

the configure_cmake.sh

I told you this sort of thing was handy :-)

[alexreinking]

I told you this sort of thing was handy :-)

Yes, you did and it is! Though I think this could still be a thin wrapper around CMake presets :)

[steven-johnson]

Yes, you did and it is! Though I think this could still be a thin wrapper around CMake presets :)

I'd be ok with that, with the caveat that I find the CMake presets stuff harder to scan and figure out quickly.

[steven-johnson]

This took me a few read-throughs -- and some experimentation! -- to fully realize how this worked, so some expanded commenting on the approach is definitely worthwhile. (I realize my original PR was similarly uncommented...)

Anyway, if I am reading this correctly, the approach you propose is that we always make a 'host' build config, but we also export a specific target (hannk_tools in this case) that can be used to build just the subset of stuff that is halide-aot code; when we really are compiling for host, this target is a no-op; when crosscompiling, we make a second cmake build config (for that), which references the export-native stuff via find_package. Is this correct?

This seems pretty slick, and could likely be scaled to work with other apps as well. (And unlike my approach, it doesn't look like it requires a hard 'subdirectory' boundary for cross-compilation, though I'd argue that's usually a good idea anyway.)

The one gotcha with approach that I see right now is that the captive 'host' sub-build we use still has to do FetchContent for stuff that isn't being build or used -- in this case, all of TFLite -- which is expensive and annoying. (Whether using FetchContent for this purpose is a separate issue, of course, but there would likely be other CMake stuff in other apps or use cases that would be desirable to subvert.) On the assumption that this sort of this is uncommon, though, maybe it would suffice to have a convention for some CMake definition that could be used to skip the FetchContent? (e.g., -DHALIDE_AOT_HOST_ONLY=ON when doing the 'captive' host build, which expensive & irrelevant parts of the CMake file could sniff for to save time?)

[alexreinking]

This took me a few read-throughs -- and some experimentation! -- to fully realize how this worked, so some expanded commenting on the approach is definitely worthwhile. (I realize my original PR was similarly uncommented...)

Anyway, if I am reading this correctly, the approach you propose is that we always make a 'host' build config,

Yep!

but we also export a specific target (hannk_tools in this case) that can be used to build just the subset of stuff that is halide-aot code; when we really are compiling for host, this target is a no-op;

This is almost right... what we're exporting are the AOT generators. It's a no-op for the cross-build, not for the host.

when crosscompiling, we make a second cmake build config (for that), which references the export-native stuff via find_package. Is this correct?

This is exactly right.

The one gotcha with approach that I see right now is that the captive 'host' sub-build we use still has to do FetchContent for stuff that isn't being build or used -- in this case, all of TFLite -- which is expensive and annoying.

Yeah, I did already notice this. I'm surprised it takes so long to download.

On the assumption that this sort of this is uncommon, though, maybe it would suffice to have a convention for some CMake definition that could be used to skip the FetchContent? (e.g., -DHALIDE_AOT_HOST_ONLY=ON when doing the 'captive' host build, which expensive & irrelevant parts of the CMake file could sniff for to save time?)

I think this is a good idea.

[steven-johnson]

OK, I think we just need a few comment changes/augmentations, addition of HALIDE_AOT_HOST_ONLY, and (maybe) the renaming of hannk_tools to something else, and we'll be good to go. (I can make these changes but won't do so unless you want me too, since this is already a PR-on-a-PR)

[alexreinking]

@steven-johnson - done. PTAL. Still TODO is improving the "ninja in the cross build directory only" workflow.

[steven-johnson]

LGTM, just waiting on green buildbots

[steven-johnson]

actually, nm, since this is merging into another PR, we'll merge it and do the buildbot tests there