Use CMake toolchain files for setting toolchain variables#161
Use CMake toolchain files for setting toolchain variables#161JAicewizard wants to merge 1 commit intoduckdb:mainfrom
Conversation
b3ef2e8 to
817acc7
Compare
|
@carlopi if there is anything against this LMK, then I will start making a PR for adding a cuda toolchain without the CMake files. I do however believe having files like this is the best for consistent duckdb (extension) compilation, and a clean way to make CMake aware of the necessary toolchain options. (Potentially, we could even fix more of the options, like always specifying exact gcc/rustc toolchains exactly to make building even more consistent.) I noticed we also rename the git linker, I think we could also specify the linker in CMake, so potentially that hack can go too. |
|
Thanks @JAicewizard! This looks to make a lot of sense, but there is quite some details, I will try to do a proper review. |
dcaeeb5 to
455c4dc
Compare
|
CI Seems to be running propperly again. I just rebased this, could you take another look at this @carlopi? The switch to almalinux on arm64 triggered some issues, since I assumed arm64 would be cross-compiled. However, this should now be fixed, and arm64 works without (and with) cross-compiling. Sorry for the commit spam, I had to try some things but I found the issue and cleaned the history |
455c4dc to
0eef88b
Compare
ec9c67d to
f64bec3
Compare
f64bec3 to
5d54cd4
Compare
Fixes #159
This propperly implements cross-compiling for the c++/c extensions, using toolchain files for each target. This allows CMake to detect when it is cross-compiling, and act accordingly. For example, CMake will set the
CMAKE_CROSS_COMPILINGvariable, which can be used by extensions as intended. The faiss extension started to support CUDA recently, and this needsCMAKE_CROSS_COMPILINGto be set for it to detect the correct libraries. Currently this is done manually in our Makefile, but this is suboptimal.The biggest benefit is the fact that all the variables are now in one place, they are no longer split between the yaml file, and the makefile. For example the rust and OSX variables were in the Makefile, but all flags relates to c and c++ were in the yaml. Having a unified location also makes adding toolchains easier. Adding the variables for CUDA would either turn the makefile into a long list of checks and a mess of variables. Being able to do this in CMake is both easier and cleaner.