Can we have a holy crusade against #Git submodules?!
Pretty please. :3

Follow

@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.

@ClickHouseCI @ambihelical

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

@ClickHouseCI @xgqt

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.

@ClickHouseCI @xgqt

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).

@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 gitlab.kitware.com/cmake/cmake

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.

@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.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.