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 ¯\_(ツ)_/¯
You dont have to rely on cmake's checkout implementation - IMHO it is the exact same as relying on git's.
I wonder if there is some very small utility that can be used instead of writing shell/python scripts to download needed things.
I would then compare hit submodules, scripts and that utility and how easy those integrate with build systems like cmake, meson, bazel, maven, etc.
@xgqt @ambihelical So, basically, one more standard to invent ¯\_(ツ)_/¯
I am interested in taking a look, but I am not enthusiastic about it. It feels like the issue doesn't have a good solution besides collecting things somewhere. And since the git is already exists, it's attractive to "just use" v_v
It's really worth it if you are stuck with CMake, it's certainly not a reason to use CMake. My main point wasn't to sell CMake but to say that having the build system control this stuff is better than git submodules.
