Open pakeke-constructor opened 1 year ago
Sorry for the long delay. I have been on vacation, then quit my job and lots of stuff has been happening.
I am a bit confused as to how it worked in the past, as there seems to be a dedicated branch for official AppImages that (I guess) worked well with just checking for liblove.so (https://github.com/pfirsich/makelove/blob/master/makelove/linux.py#L234).
That whole liblove check is only relevant when shared_libraries
is defined in the config, right? So it's not super, super broken, I think? Would you (or anyone reading) be willing to contribute the necessary fixes? I'd probably replace that block with something like this:
so_target_dir = find_liblove([
appdir("lib/"), # pfirsich-style AppImages
appdir("usr/lib"), # Official AppImages (since 11.4)
])
if so_target_dir == None:
sys.exit("Could not find liblove.so in AppDir. The AppImage has an unknown format.")
and do find_liblove
like this maybe?
def find_liblove(search_dirs: list[str]):
is_liblove = lambda fname: fname.startswith("liblove") and fname.endswith(".so")
for search_dir in search_dirs:
if any(is_liblove(f) for f in os.listdir(search_dir)):
return search_dir
return None
This is not tested or anything. And you can do it a different way too, if you want.
Hi- I have been using love with a custom AppImage, (specifically, the latest love-12 AppImage generated from github actions).
The new Love-12 appImages contain
liblove-12.so
as opposed toliblove.so
, which is breaking makelove.I'm not sure why this was renamed, I've asked on the love discord.I had a discussion with Sasha, turns outliblove
has always been named this way. I think it's just because I got the extracted appimage from the github CI, why there were issues.What do you think about this? Would it be worth making the
liblove
detection a bit more generic to detect different versions....?I also suspect that this was the cause of #38
(For reference, here is a tree of the new extracted appimage for love 12)