3 ms·
There are very good reasons for closed source projects in fact not to use public repositories but the very least org-internal forks/mirrors. In that case depend
by fsloth 2y ago
There are very good reasons for closed source projects in fact not to use public repositories but the very least org-internal forks/mirrors. In that case dependency management referring fixed public repositories is no-go. If there are better solutions than submodules for these I would love to know. Fetch-content might do the trick? (Specifically, a complex project composed only of private git repositories).
- delta_p_delta_x 2y ago> If there are better solutions than submodules for these I would love to know. https://learn.microsoft.com/en-gb/vcpkg/concepts/registries https://learn.microsoft.com/en-gb/vcpkg/concepts/registries and In essence: - Publish your local/private mirror of the 3rd-party dep - Edit the portfile for each dependency to point to your private repo, usually in `vcpkg_from_git`, `vcpkg_from_github`, `vcpkg_from_gitlab`, or `vcpkg_from_bitbucket` - Publish these portfiles to your private vcpkg registry - Set the registry in vcpkg-configuration.json (or the `vcpkg-configuration` field in vcpkg.json) to your private registry Done.
- fsloth 2y agoThank you!
- spookie 2y agoI prefer ExternalProject_Add because that way I have full control of the build process. Adding even more abstractions leads to issues, edge cases and the like.