Add CMake build rules for (some) of the generator jit tests

[steven-johnson]

Amazingly, these have been TODO for ~ever. This adds two of them; registration_test and rungen_test will be added subsequently (assuming this PR works).

[alexreinking]

This is unused but really shouldn't be... which target consumes it? It should be listed in the target_sources of that target.

[steven-johnson]

Hrm, ok.

I'm also baffled by the build failures in apps/hannk -- something has somehow tickled the include paths in a way that makes no obvious sense to me.

[steven-johnson]

This is unused but really shouldn't be... which target consumes it? It should be listed in the target_sources of that target.

It's just a header file -- do those need to be in target_sources in CMake?

[steven-johnson]

Ping re "It's just a header file -- do those need to be in target_sources in CMake?"

[alexreinking]

It's just a header file -- do those need to be in target_sources in CMake?

If the header file is generated, then it should be listed in some target, yes. Either:

1. Directly among the PRIVATE sources of the unique target that consumes it.
2. As a DEPENDS of a custom target; other targets that use the header should add_dependencies to that target.

[steven-johnson]

Monday morning review ping

[steven-johnson]

Monday morning review ping, again

[steven-johnson]

Pingity ping ping ping

[steven-johnson]

♫ Old McDonald had a ping
Pingity pingity ping ♫

[steven-johnson]

Re-adding @alexreinking -- the reason that apps/hannk is now failing is because of the insertion of the generator "library" for cpp_stub usage... previously, adding a dep to a Generator could be done by just doing target_link_libraries(foo.generator ... ); now, that doesn't actually help, because you would need to do target_link_libraries(foo.generator_lib ... ) for it to actually work.

Ugly options:

• Add a DEPS argument to the add_halide_generator() rule. Would work, but would break existing code. (And maybe be a weird thing for CMake users? Dunno, it's all still weird to me.)
• Build the library for cpp-stub usage separately from the generator exe (ie, redundantly). This would maintain existing usage, but means that the hidden _lib target would need explicit attention from users that need to add deps to it.
• Something else? For good or ill, we can't do the JIT tests without the cpp-stub stuff (even though cpp-stub stuff is gross and awful, but we can't delete it just yet).

[steven-johnson]

Post-vacation ping to @alexreinking

[steven-johnson]

Bride of Return of Ping to @alexreinking

[alexreinking]

There's a nice...ish... way to do this in CMake 3.27 (latest) that I outlined in the review suggestions. You create an interface library that propagates the links / includes and object files (filtering out GenGen.cpp.o is 3.27+).

For now, I'd prefer to preserve existing usage since an eventual upgrade to CMake will allow us to do that anyway. Maybe only build redundantly if the cpp stubs are requested via the argument?

[alexreinking]

• Add a DEPS argument to the add_halide_generator() rule. Would work, but would break existing code. (And maybe be a weird thing for CMake users? Dunno, it's all still weird to me.)

This already exists as LINK_LIBRARIES doesn't it?

• Build the library for cpp-stub usage separately from the generator exe (ie, redundantly). This would maintain existing usage, but means that the hidden _lib target would need explicit attention from users that need to add deps to it.

I think this is the way to go given our current CMake version.