Teach Halide CMake build to export Halide library target

[delcypher]

This will allow other CMake projects to import the Halide library (however it's built, e.g. dynamic or static). It also allows a required libraries/compiler flags to be exported to the client if need be. We can also have the HalideGenerator.cmake automatically imported for the client when they do find_package(Halide CONFIG REQUIRED).

A use case for this is app/wavelet which tries to be standalone but doesn't quite succeed due to the static in source build assumption.

I've done this before for the STP project so it should be fairly straight forward to do.

[ibtaylor]

This seems like a requirement when statically linking a program against Halide. Right now, it seems difficult to do this because the transitive dependencies are lost. Right now, it seems like a project statically linking against halide would have to find all the llvm components as well, which is weird because these can probably change depending on how halide was compiled.

Seems like the more modern way is to use this?
https://cmake.org/cmake/help/v3.8/module/CMakePackageConfigHelpers.html

[abadams]

Static builds of Halide (using the Makefile at least), bundle the relevant parts of llvm inside libHalide.a, so there shouldn't be transitive dependency issues. I take it the cmake build isn't doing that?

…

On Tue, May 30, 2017 at 12:54 PM, Ian Taylor ***@***.***> wrote: This seems like a requirement when statically linking a program against Halide. Right now, it seems difficult to do this because the transitive dependencies are lost. Right now, it seems like a project statically linking against halide would have to find all the llvm components as well, which is weird because these can probably change depending on how halide was compiled. Seems like the more modern way is to use this? https://cmake.org/cmake/help/v3.8/module/CMakePackageConfigHelpers.html — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#870 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAfdRkaIzbIUJcw3J3DaJZqLRfVVDT5Rks5r_HQNgaJpZM4FeyES> .

[ibtaylor]

Doesn't appear to be.

I get a lot of undefined references to llvm::*

[ibtaylor]

When compiling against Halide, I need to additionally link against libdl. This seems to come from src/runtime/*_get_symbol.cpp, hexagon_remote.cpp and maybe src/JITModule.cpp.

I guess I'm noticing this now because in the past I have linked against additional libraries that have dragged in that dependency.

I guess this isn't a dependency in the static case if you also drag in these objects from libdl.a?

I know it's not fun, but maybe providing a cmake config script is the best way for Halide users using cmake to have robust builds. I currently use a FindHalide.cmake which just isn't going to be as robust as halide providing one since it knows all the details of its compilation. This would also allow for people who want Halide linked against the LLVM shared libraries to have much more robust builds.

@abadams I could expend some effort on this and make a PR if this is something the authors of Halide would accept.

[steven-johnson]

We would love to have someone work on improving our CMake support; it usually gets minimal-effort necessary from our team, mainly because it exists pretty much only to do Windows builds/tests.

[delcypher]

@ibtaylor If you work on this I'd happily review it. I did something similar for another project I worked on recently.

[alexreinking]

What is the status of this? Are people using the CMake build? I would be very interested in improving Windows support.

[steven-johnson]

I don't think any of the "core" Halide contributors use CMake very much, though I could be wrong. As I said in an earliest comment, we'd be super-happy to have someone work on improving our CMake support.

[alexreinking]

This will be fixed by #4644