Issues with the release Task in Makefile

[sys9kdr]

Problem

There are issues with the release tasks in the current Makefile, such as release_prepare, release_linux, and release_macos, which are not correctly generating the release files. For example, the macOS build outputs the following:

$ tar -tf hashlink-d8f2ddc-darwin.tar.gz
hashlink-d8f2ddc-darwin/
hashlink-d8f2ddc-darwin/sqlite.hdll
hashlink-d8f2ddc-darwin/ui.hdll
hashlink-d8f2ddc-darwin/hl
hashlink-d8f2ddc-darwin/openal.hdll
hashlink-d8f2ddc-darwin/ssl.hdll
hashlink-d8f2ddc-darwin/include/
hashlink-d8f2ddc-darwin/uv.hdll
hashlink-d8f2ddc-darwin/libhl.dylib
hashlink-d8f2ddc-darwin/sdl.hdll
hashlink-d8f2ddc-darwin/mysql.hdll
hashlink-d8f2ddc-darwin/fmt.hdll
hashlink-d8f2ddc-darwin/include/hlc.h
hashlink-d8f2ddc-darwin/include/hlc_main.c
hashlink-d8f2ddc-darwin/include/hl.h

This issue is affecting the generation of proper release files.

Solution

Fix Makefile, or switch to cmake completely.

[tobil4sk]

What exactly is the issue with it? Is the hl executable failing to load the libhl.dylib and .hdll files?

[sys9kdr]

I believe the make release command should produce the same structure as the CMake build does. The CMake builds include bin, lib, and include folders, like this:

$ tar tf hashlink-94a3037-linux-amd64-cmake.tar.gz
hashlink-94a3037-linux-amd64-cmake/lib/
hashlink-94a3037-linux-amd64-cmake/lib/uv.hdll
hashlink-94a3037-linux-amd64-cmake/lib/openal.hdll
hashlink-94a3037-linux-amd64-cmake/lib/libhl.so.1.14.0
hashlink-94a3037-linux-amd64-cmake/lib/sdl.hdll
hashlink-94a3037-linux-amd64-cmake/lib/sqlite.hdll
hashlink-94a3037-linux-amd64-cmake/lib/fmt.hdll
hashlink-94a3037-linux-amd64-cmake/lib/libhl.so.1
hashlink-94a3037-linux-amd64-cmake/lib/ssl.hdll
hashlink-94a3037-linux-amd64-cmake/lib/ui.hdll
hashlink-94a3037-linux-amd64-cmake/lib/libhl.so
hashlink-94a3037-linux-amd64-cmake/bin/
hashlink-94a3037-linux-amd64-cmake/bin/hl
hashlink-94a3037-linux-amd64-cmake/include/
hashlink-94a3037-linux-amd64-cmake/include/hlc.h
hashlink-94a3037-linux-amd64-cmake/include/hl.h
hashlink-94a3037-linux-amd64-cmake/include/hlc_main.c

This structure is more easy for install/uninstall.

[sys9kdr]

Personally, I think it's better to create a subdirectory like /usr/local/lib/hashlink or /usr/local/lib/hl and store the .so files there.

[yuxiaomao]

In fact, Makefile/VS & Windows is the primary maintained build tool and platform. Additionally, this structure makes it easier to distribute game with binaries in all platforms. So we won't change this.
If you'd like to download cmake nightly build for install, you can adapt your PR to upload cmake artifacts in addition of the current make release.

[tobil4sk]

On linux/mac, if you want to install the binaries properly on your system is better to build from source or to install via a system package manager (or homebrew for mac). This ensures that the binaries are placed in the correct system directories (bin, lib, etc) and will ensure that the libraries load correctly. It also avoids issues with missing dynamic libraries: #595.

Personally, I think it's better to create a subdirectory like /usr/local/lib/hashlink or /usr/local/lib/hl and store the .so files there.

I'm not sure if this makes sense for libhl.so. Maybe it would make sense for the hdlls and this is what neko used to do, however, this would be a breaking change.

[sys9kdr]

I know self-build is best for installing. But I like just download, extract and put files. It's easy.

In this downloading case, current structure is not good.
No one wants to put share objects directly into /usr/local/bin.

I'm not sure if this makes sense for libhl.so. Maybe it would make sense for the hdlls and this is what neko used to do, however, this would be a breaking change.

I thought this way is easy to manage share objects and include files. Some tools use subdirs.

[tobil4sk]

I know self-build is best for installing. But I like just download, extract and put files. It's easy.

Any reason why you'd prefer this over installing from homebrew? That is also simple, it downloads and installs the binaries for you and it will also take care of updating hashlink or uninstalling it properly if you want to uninstall.

I'd say it is better to use a package manager when touching /usr/local anyway, rather than placing files in there manually.

No one wants to put share objects directly into /usr/local/bin.

Yes, this would definitely be wrong, however, It is still possible to manually sort the files into the correct directories.

[sys9kdr]

cause I'm Linux guy.

Currently Hashlink's distribution style is not comfortable with asdf(mise), simple bash script or other installation(not build) way.