DDraceNetwork - developer

ddnet-maps

[ddnet-maps:master] 1 new commit

f53e67a A Gehenna - ddnet-maps

any reason ddnet doesn't use submodules on a per-dependency basis?

Why should it

For one, if in the future this dependency repo doesn't exist, you won't be able to fetch them & will have to have them installed And it's just another link in the potential chain of failure, and I'm not sure what the benefit of having them in their own repo is other than observed tidiness If you need a particular configuration of snapshot commits in each submodule, I'm not sure why you can't just do that with each commit in the ddnet repo

It would be more useful to use cmake sub directories

08:00

So it Auto compiles the dependencies

I didn't realize it doesn't do that already. But that's not strictly related to how they're fetched

08:00

Just having a deps subdir or something makes more sense, in my opinion

our dependencies are handled by package managers like apt

08:01

i doubt they would disappear, they are not on a github repo

08:01

actually, i would be more worried about github disappearing

Anyway I don't see the breaking thing u mention. Old versions have old submodule commits

I suppose this is something you couldn't do without having it the way it is now

Ah yeah SDL is always fun on windows and macos

Ewan

I suppose this is something you couldn't do without having it the way it is now

this is my q answered then

08:04

i was just thinking about how I would have done it; by getting the deps directly in their own submodules

08:04

and i doubt having them in their own repo was the first choice/how it was from the start. there was probably something that made this necessary, right?

I think the best is to use a packet manager. There is for example vcpkg https://vcpkg.io/en/index.html Or Conan but I dunno

vcpkg - Open source C/C++ dependency manager from Microsoft

vcpkg product homepage for C and C++ developers. Download, build, and manage C and C++ libraries for all platforms, buildsystems, and workflows.

Ryozuki

our dependencies are handled by package managers like apt

If that's the case, I would be kind of concerned

Releases of libraries that get published to package managers are more second-class instances than those on the upstream repo's main branch, which (if the library has competent maintainers) shouldn't break. Just because they are less common
Releases of libraries that get published to package managers may be much more prone to disappear or stop being maintained, because often times the demand isn't high enough or such deployment is handled by a third party
A break in your package-fetching CI or the package's local install scripts, or the package manager itself leaves you open to problems where submodules are more sound -- not perfect, but less prone to disappearance at any given moment

08:12

And if you're using a library that doesn't have a git instance somewhere (GH or GitLab), either host it yourself or find something more modern/better maintained

08:13

In current year that's pretty much a necessity

08:14

I'm pretty much positive everything here has an official repository

08:14

Build steps are trivial

Anyway. U'll need to accept almost all devs here are Linux devs and simply use the os package manager

Yeah fair enough

08:16

Depending on system local libs is good practice if a solution like what you have in place is around

08:16

I just wonder why it's been executed this way...

Probably BCS teeworlds did it like this

08:17

And the code base is over 13 years old

Well that would have been a good answer from the start xD

Good thing is, we added rust support which comes with cargo. Which handles dependencies cleanly

Yeah... rust dependencies, maybe

So maybe it changes in future anyway

Ewan

For one, if in the future this dependency repo doesn't exist, you won't be able to fetch them & will have to have them installed And it's just another link in the potential chain of failure, and I'm not sure what the benefit of having them in their own repo is other than observed tidiness If you need a particular configuration of snapshot commits in each submodule, I'm not sure why you can't just do that with each commit in the ddnet repo

it's to not balloon the size of the ddnet repo (edited)

Ewan

I'm pretty much positive everything here has an official repository

discord likely doesn't. sqlite3 doesn't want to be compiled from the repo. curl likely has one, not sure if they want to be compiled from the repo. rest I don't know about

They don't want to be compiled from repo? That sounds kinda stupid xd

09:11

Is our SQLite built not self built?

but from a release, I'd hope

09:14

https://sqlite.org/howtocompile.html

09:14

The use of the amalgamation is recommended for all applications.

>

Building SQLite directly from individual source code files is certainly possible, but it is not recommended. For some specialized applications, it might be necessary to modify the build process in ways that cannot be done using just the prebuilt amalgamation source file downloaded from the website. For those situations, it is recommended that a customized amalgamation be built (as described below) and used. In other words, even if a project requires building SQLite beginning with individual source files, it is still recommended that an amalgamation source file be used as an intermediate step.

(edited)

Mh ok. SQLite is weird anyway

Ewan

and i doubt having them in their own repo was the first choice/how it was from the start. there was probably something that made this necessary, right?

Repo size

Submodules

Ah heinrich answered before me

Ewan

Submodules

Hm, isn't that what we did?

My question was more why they’re not in their own submodules

You mean 1 per dependency? I guess we didn't really see a benefit to it

Yeah. I was told that’s how it was done in teeworlds

We don't mind straying from tw in those kinds of things, if we'd seen a reason to do that we would have I think

09:32

Why do you think it'd be better to have them in separate repos?

I explained a fair amount above. If you’re interested you can scroll, it’s not too far

I think main reason Ewan pointed out was those modules going extinct and being less stable than if they would be taken from a repository. (edited)

Ewan

For one, if in the future this dependency repo doesn't exist, you won't be able to fetch them & will have to have them installed And it's just another link in the potential chain of failure, and I'm not sure what the benefit of having them in their own repo is other than observed tidiness If you need a particular configuration of snapshot commits in each submodule, I'm not sure why you can't just do that with each commit in the ddnet repo

If 1 repo with all dependencies can disappear, so can more than one. I don't see why amount of repos changes anything.

09:38

Or maybe you mean have their entire sources instead of built dependencies?

Yeah, but that’s not entirely feasible with the discord/curl/sqlite developments

09:39

But, some prebuilts is better than all, IMO

I guess that is doable, we do already build some of these on our own

I’d be happy to stage some changes

>DDNet will outlive curl & sqlite

Huh?

Isn't that why you want them to build it themself?

09:50

Because I don't know how this world works. But their repos and modules will exist for a long time. No reason for them to delete it as long people use it. (edited)

Building with dependency sources vs. dynamic libs can decrease package size with LTOs. My point wasn’t that the libraries would croak, but the ways they’re deployed & used by ddnet

Ewan

I’d be happy to stage some changes

I wouldn't start anything without getting some agreement in place. We have many scripts building stuff that'd need changing. If linkage is changing we have some interesting linking quirks (like the curl stub). Our CI times(or build times in general) are also a concern, so some sort of prebuilt dependency will need to be there. We have a flatpak release that'll need those too