Symlink incorrectly installs to a sub-directory related to source name (github: 80)

This bug is a mirror of the GitHub issue https://github.com/zyga/zmk/issues/80 filed for the purpose of SRU

The following makefile snippet illustrates the problem:

# Symlink: sysota-rauc-hook -> sysotad
cmd/sysotad/sysota-rauc-hook.InstallDir = $(cmd/sysotad/sysotad.InstallDir)
cmd/sysotad/sysota-rauc-hook.SymlinkTarget = sysotad
$(eval $(call ZMK.Expand,Symlink,cmd/sysotad/sysota-rauc-hook))

The result of make install should be

ln -s sysotad /usr/lib/sysotad/sysotad-rauc-hook

With zmk << 0.5.1 it is

ln -s sysotad /usr/lib/sysotad/cmd/sysotad/sysotad-rauc-hook

This bug was fixed in zmk 0.5.1, which is available in Debian Unstable and Ubuntu Impish as 0.5.1-2

[Impact]

The issue is isolated to the ZMK Symlink template and is only visible when the path of the symbolic link, in the development tree, contains a sub-directory, like in the RAUC hook example above.

[Test Case]
Create a makefile with this content:

include z.mk
$(eval $(call ZMK.Import,Directories))
subdir/symlink.InstallDir = $(bindir)
subdir/symlink.SymlinkTarget = target
$(eval $(call ZMK.Expand,Symlink,subdir/symlink))

Issue the command: make -n install. The correct output is:

ln -sf target /usr/local/bin/symlink

In the broken case, the output is:

ln -sf target /usr/local/bin/subdir/symlink

[Where problems could occur]
Since zmk is only used by my own software, most notably libzt, and libzt does not trigger this error, the regression potential is minimal.