Closed saltedcoffii closed 2 years ago
Hi! Are you talking about the following structure:
.
├── bin
│ ├── tgs_to_gif.sh
│ ├── tgs_to_png
│ ├── tgs_to_png.sh
│ └── tgs_to_webp.sh
└── src
I am, kind of. Have a look at https://aur.archlinux.org/packages/tgs-to-gif-cpp-git and see how they package it. you can see how it's not ideal.
I am not cmake guru. so @saltedcoffii, I would be happy if you review the pull request #75 :)
Alright! I'm not a cmake guru myself either but I use this program a lot and would love to learn! I have a lot more experience with meson, if I changed the buildsystem to that, would that be okay? If not, we'll see if I can learn cmake.
in case of switching to meson
thank you @saltedcoffii!
Statically linking the tgs_to_png binary against rlottie makes integration with an actual system difficult, e.g., on linux, where
rlottie
may already exist in a dynamic library form. Additionally, should there be any patches or updates torlottie
, the new.so
library won't be used by the static binary.All the scripts
tgs_to_png
,tgs_to_gif.sh
tgs_to_webp.sh
andtgs_to_png.sh
all having to be in the same directory makes installing as a package in a linux distro very awkward.tgs_to_png.sh
isn't executable, but still must be in the/usr/bin
directory with the rest of the files, instead of likely fitting better in/usr/share/tgs-to-gif/
, for example.Please provide an option at some point during compilation to enable a “distro mode” of sorts to mitigate these issues.