Can we have a holy crusade against #Git submodules?!
Pretty please. :3
@xgqt personally I haven’t had issues with them. But I will say after having used cmake fetchcontent for awhile that pulling in dependencies with a build system is much more flexible and easier to use.
@ambihelical @xgqt interesting. I've took a look on https://cmake.org/cmake/help/latest/module/FetchContent.html#command:fetchcontent_declare, then on https://discourse.cmake.org/t/fetching-from-github-with-depth-setting/578, and finally at https://gitlab.kitware.com/cmake/cmake/-/issues/17770
And it looks to me, like it will have 100% the same issues as submodules ¯\_(ツ)_/¯
Yeah I don't know what those supposed issues are with git submodules, so I can't say. But there are notable differences w/respect to git submodules. One is that the repo population happens at build time instead of repo checkout or update time. And also it's easy to make repos conditional on cmake variables. In addition if for whatever a subtree of your project isn't built (e.g. some optional part), the fetchcontent repos defined in that subtree are not fetched. Also the SHAs or branch names are not hidden away, but are in the same files you use to configure your build (or separate, your choice).
@ClickHouseCI @xgqt Thanks, I wasn't aware of these issues. I guess I'm fortunate not to have any of them, as I work in an embedded environment (5-10 small repos).
I know it can work with a local git server, that's how we use it, but technically that's still "internet". You can also use a file path source, I use that sometimes for developing related repos, but I'm not sure how useful it would be in general, as there is no version control from the build system, and repeatability becomes a problem. Not sure I understand your use case though.
@ambihelical @xgqt on one hand, it's very cool. On the other hand, cmake requiring an internet connection is rather a flaw in our cases.
And the case why it doesn't solve anything, it's just another level, where the completely same technology is hidden from us. But with it's own bugs https://gitlab.kitware.com/cmake/cmake/-/issues/17770
Our main issue is checkout time and traffic. And it looks like the new scheme will make things worse. Because there's no parallelism out of the box. And the shallow checkout is broken.