CMake AOT Problem #5336
-
Hi, I explicitly try to separate the AOT compilation in a generator and a runner part. The runner should not depend on libHalide as mentioned here. My Halide project looks like this:
The /gen/CMakeLists.txt looks as follows:
The generator in gen.cpp is the same as shown here. When I invoke
The /run/CMakeLists.txt looks as follows:
The run.cpp only includes HalideBuffer.h and ../gen/blur.h. When I invoke
I am using Ubuntu 18.04 with LLVM 10.0.0 and build Halide from the master branch. I am a beginner in CMake and Halide and tried to follow this guide to set up the CMakeLists. Could you please provide me some help to solve this issue or share a minimum example on how to set up such a separated AOT compilation in CMake? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
The short answer is that you aren't linking to The long answer is that if you want to split up compilation like this, then you should export / install the library target from the I've been meaning to put together an example of this for multi-toolchain cross-compilation for a while, but I have paper deadlines coming up, so I won't be able to get to it for a couple months. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your help and advice Alex (nice talk at cppcon btw 👍). My /run/CMakeLists.txt now looks as follows:
As you already pointed out, using system-specific paths in CMake is propably not best practice, so I removed them and also exported and install the generated libraries as suggested. Here is my solution: The /gen/CMakeLists.txt now looks as follows:
I run the following commands to make the generator:
The /run/CMakeLists.txt now looks as follows:
I run the following commands to make the runner:
|
Beta Was this translation helpful? Give feedback.
The short answer is that you aren't linking to
libblur.runtime.a
.The long answer is that if you want to split up compilation like this, then you should export / install the library target from the
gen
project and thenfind_package
from therun
project to get those targets. Then you would usetarget_link_libraries
to link to the imported target rather than a system-specific path embedded in the CMake file (you should really never do this).I've been meaning to put together an example of this for multi-toolchain cross-compilation for a while, but I have paper deadlines coming up, so I won't be able to get to it for a couple months.