Open Vladik01-11 opened 1 month ago
Yeah, there's no clear best-path here I think. I usually only lock the dependant (tacent) before a release -- during dev I just add at head whatever I need to tacent, add the unit tests, and that's it. A cmake reconfigure of the viewer then handles everything. The benefits of cmake's fetch / make-available are it handles trees of deps very well (no duplicated shared submodules... cuz it's done at configure-time), dependencies are kept within cmake, it is not tied to any particular revision control system (a dep can be from git, svn, tar-file, etc). The downside is cmake needs to be used. There are some projects going the other direction: https://github.com/apache/kvrocks/issues/562
Right now the biggest issue is probably all the deps tacent has -- the image loading libs (if not written from scratch like the tga loader) are all built offline and checked in as prebuilt libs. For example, I know zlib is used be a few of them, and tiff is a container around a few different formats -- even ico files can have pngs inside them. For the most part tacent shares pixel decoders where it can... but point being once this is sorted out using fetch becomes more of a winner. Incidentally a search for "fetchcontent versus submodules" gives some interesting links.
I suggest replacing the CMake SubModule variation with the one from GIT as examples of SubModule usage: https://github.com/gta-reversed/gta-reversed-modern https://github.com/emanuele-f/PCAPdroid
When you change something in Tacent, you most often change the Tag in CMakeList.txt, which makes it unclear right in the TacentView repository what changes were made, but when you put Tacent as a SubModule for GIT you can see the diff In addition, from GitHub you can bind a Dependabot bot that will automatically create PRs when any SubModule is updated (it can be customized somehow, but that's if you decide to add it)