In fc25d2b the build instructions were removed and replaced with using Nix. In 7c268df the git submodules were removed.
This doesn't seem suitable for use within another package manager. For example, if a user wants to install Pingus with MacPorts, they don't want to have to also install the competing package manager Nix first, nor do they want MacPorts to automatically install Nix for them. This prevents me from being able to update Pingus in MacPorts to the latest commit.
For any well-known dependencies like SDL, the user wants MacPorts to manage the installation of those dependencies. And for any esoteric dependencies used only by your project, it's reasonable to build them from source as part of your build, as you were previously doing with submodules.
Is there still a way to accomplish this? I don't mind having MacPorts fetch the esoteric dependencies manually since the submodules are gone. The best option would be for you to tag your releases (#197) and create a GitHub release for each such tag to which you attach a complete tarball containing both your code and the esoteric third-party projects you use.
In fc25d2b the build instructions were removed and replaced with using Nix. In 7c268df the git submodules were removed.
This doesn't seem suitable for use within another package manager. For example, if a user wants to install Pingus with MacPorts, they don't want to have to also install the competing package manager Nix first, nor do they want MacPorts to automatically install Nix for them. This prevents me from being able to update Pingus in MacPorts to the latest commit.
For any well-known dependencies like SDL, the user wants MacPorts to manage the installation of those dependencies. And for any esoteric dependencies used only by your project, it's reasonable to build them from source as part of your build, as you were previously doing with submodules.
Is there still a way to accomplish this? I don't mind having MacPorts fetch the esoteric dependencies manually since the submodules are gone. The best option would be for you to tag your releases (#197) and create a GitHub release for each such tag to which you attach a complete tarball containing both your code and the esoteric third-party projects you use.