Closed tobil4sk closed 2 months ago
Hi, I never used cmake, could you please detail a little bit how to use cmake for generation and what libraries ends up in lib
? Especially, it that possible to just adjust where is the HASHLINK variables?
I know that I have made ci
template, where I have to split src directory and dll directory, I'm wondering if that's a similar problem.
Hi, I never used cmake, could you please detail a little bit how to use cmake for generation and what libraries ends up in lib? Especially, it that possible to just adjust where is the HASHLINK variables?
These are the rough steps to build and install via cmake:
mkdir build
cd build
cmake ..
cmake --build .
# this last step is currently missing from haxe ci:
cmake --build . --target install
The cmake install generates the following directories in the install directory:
bin
: this contains hl.exe
and libhl.dll
include
: hl.h
hlc.h
, but currently missing hlc_main.c
(needs #517)lib
: all .hdll
and .lib
filesYou can see the structure of the generated windows-cmake-64
artefacts: https://github.com/HaxeFoundation/hashlink/actions/runs/10735720378/artifacts/1900367023
If it is preferred, an alternative would be to change the cmake install structure on windows to match what is generated for the vs2019 builds? Then we don't need this PR, that might be simpler and it is how neko used to install.
I know that I have made ci template, where I have to split src directory and dll directory, I'm wondering if that's a similar problem.
Yes, I'm trying to solve a similar problem. With #517 and if this issue is solved, then haxe ci can just add the cmake install step (and set only HASHLINK
) and there should no longer be a need for a special ci
template. I think it is ideal for CI to build with the same template that a regular user will be using.
Thank you for the explanation! I just did a quick search on CMake and merged the other PR, as it can help CMake users x). I see that CMake generate bin/include/lib structure for all targets, and this structure is different than what make/vs2019 generates. If possible, I think it would better to let them generate the same structure and keep things simple?
I just did a quick search on CMake and merged the other PR, as it can help CMake users x).
Thanks!
If possible, I think it would better to let them generate the same structure and keep things simple?
Ok, that sounds good. I'll open a new PR that does that instead!
I've opened: #709
When hashlink is installed via cmake, the library files end up in the
lib
subdirectory