Open tobil4sk opened 2 months ago
Small documentation / default value handling issue:
Set hlgen.makefile for automatic native compilation
But adding -D hlgen.makefile
(without setting a value) gives:
Automatic native compilation not yet implemented for 1
If picking a default value is not something we want, it would be nice to list correct values in this error message I think?
If picking a default value is not something we want, it would be nice to list correct values in this error message I think?
The default value was working before, I just forgot about it with my changes so this should be fixed. Maybe it should be updated though:
Aside from this, the makefile here doesn't support mac at the moment (mac linker doesn't support -l:fmt.hdll
syntax). This will have to be fixed before this can be merged. -lfmt.hdll
doesn't work because hdll libraries don't follow the standard naming of lib[name].so
. We can instead link with the full path /usr/local/lib/fmt.hdll
, however, on linux this hardcodes the full path for loading the library, unless fmt.hdll
is built with -soname
(already the case with the hashlink cmake file, but not the hashlink make file). So there are two options:
-soname
on linux.
This adds two new templates to the hashlink support library to simplify hlc compilation:
make
for a regular Makefile, andhxcpp
for a Build.xml. Both of these implement automated compilation, so if you add either of these then an executable is generated automatically:The Makefile is smart so it will only recompile files whose dependencies have changed. I've tested it on Linux and on Windows with mingw.
Like with the Visual Studio templates, on Windows the templates expect a
HASHLINK
environment variable to point to the hashlink installation. With the Build.xml template, the installation can also point to the hashlink sources, provided that they contain binaries generated byhl.sln
.