Removing dependency binaries

[Elias Daler]

Yeah, I think it'll be cool to handle SFML_USE_SYSTEM_DEPS and not build dependencies, but otherwise I see that they indeed need to be statically linked into SFML's libs.

[Jonny]

RE SFML_USE_SYSTEM_DEPS - I agree, this is also what I suggested earlier.

I still would prefer to use git submodules over just copy/pasting the code into the repo. I will concede it adds a tiny bit of complexity for the end user, but I think it makes it easier for contributors, particularly for maintenance and testing features/bugs in different versions of dependencies. Other than having to add an extra parameter to your first clone of the repo, all the downsides of submodules are also present when just including the raw source

I don't feel particularly strongly about it though, so I'd rather just decide on a direction so we can start implementing something

For reference, freetype2 takes <8 seconds to build on my laptop, I doubt there's much deviance from that

Update: Having gone back to the work I've done previously on this, one of the larger issues is handling the target exports as we need all the dependency targets to be part of the export target, assuming we use add_subdirectory. This might require a small amount of patching for each dependency

Another update: Proof of concept using submodules here if anyone wants to check it out https://github.com/JonnyPtn/SFML/tree/build_deps .Having a slight issue on macOS where there's an openAL thread chewing up all the CPU (any ideas on that?). Otherwise, it's working pretty well

[eXpl0it3r]

To me either way would work, as such I've simply added a poll, so hopefully those who didn't want to say something, can still weigh in with their vote.

[Nexus]

I'm with FRex on this. In my personal experience, Git submodules were a pain every single time I had to do more with them than just git clone --recurse-submodules.

Before we go this route, we should really be clear where we see the advantage over including the source.
Some disadvantages were already mentioned:

• Less user-friendly for every SFML user due to extra setup step (you can expect 100s of forum posts "why does my code not compile")
• We introduce a third-party dependency. If that third-party repository goes down, SFML will not be possible to build, with no backup (rolling back to previous version past now won't work)
• It's not even clear if all the dependencies we currently use have official and stable Git repos. If not, we would need to provide a mirror (i.e. extra maintenance).
• There's quite some hidden complexity in the Git Submodule design, see here. This can lead to unnecessarily complex workflows for both maintainers and users.

There's also different mechanism to version external dependencies: git-subtree.
Its usage and advantages over git-submodule are explained nicely in this StackOverflow answer.
I've personally used it (or its predecessor, before it was in Git) to pull Aurora into Thor, and it worked very well.

And I would appreciate if the decision were made based on technical arguments, not polls from a handful of people that happen to be around at the time the matter is discussed

[Jonny]

Git submodules were a pain every single time I had to do more with them than just git clone --recurse-submodules.

You wouldn't have to do anything more with them than just git clone --recurse-submodules

Less user-friendly for every SFML user due to extra setup step (you can expect 100s of forum posts "why does my code not compile")

It can be made extremely simple. We can use cmake show a warning if the user hasn't cloned the submodules, telling them exactly which command to run. We can also use cmake to actually check out the submodules if the user hasn't already

We introduce a third-party dependency. If that third-party repository goes down, SFML will not be possible to build, with no backup (rolling back to previous version past now won't work)

Given all the repositories except one are hosted on github, the likelihood of this being an issue is almost nil. If it's a concern we can also easily mirror them in repos we have control over

It's not even clear if all the dependencies we currently use have official and stable Git repos. If not, we would need to provide a mirror (i.e. extra maintenance).

They all have official git repositories, and even IF we were to mirror them (which I don't think we need to do) the maintenance would be equal to maintaining the source in the SFML repo (i.e. almost nil)

subtree looks interesting. Haven't tried it myself but worth considering. I'd be interested to see and try a working example of it

And I would appreciate if the decision were made based on technical arguments, not polls from a handful of people that happen to be around at the time the matter is discussed

I think we've pretty much already covered all the technical arguments, there's not really too many facets to discuss. At this point it comes down to personal preference, so a poll seems reasonable.

In the interest of fairness, here are the submodule advantages that were already mentioned:

• Better visibility over dependency versions
• Easier testing of newer dependency versions (just git checkout/pull the revision you want to test)
• Easier access to dependency history for bisecting/debugging/testing
• Less risk of human error when updating or changing dependencies
• Easier to contribute changes upstream

As I said before I don't think there's a clear technical reason to choose one or the the other (They are almost identical in practice) so we just need a decision made. It's super easy to change and the implementation is pretty much done. We just need a decision so this doesn't turn into another dead discussion

[Nexus]

OK, thanks for listing it clearly! So I think it boils down to decide what's more important for SFML:

• git-submodule: have full traceability / version switching and the option to contribute upstream, at the risk of having the build break because of unavailable 3rd-party repos and extra inconvenience when cloning and updating SFML.*
• git-subtree: have self-contained and always-available repo that retains current easy workflow for users, at the cost of extra manual work for SFML developers in case they want to try different versions or contribute upstream.

Since I would argue that it's more important to make life easier for SFML users (the "S"), and that the cases we're discussing -- trying different versions of a dependency and contributing upstream -- occur rarely enough, git-subtree is more suitable in my opinion. I'm not a fan of imposing extra constraints and a more complex workflow for the average user, just to make developer life slightly easier in one of those rare scenarios. We haven't had those options until now and it was never a severe restriction.

Edit: the problem with polls is that the voters don't represent the users being affected. The average SFML user isn't necessarily active in this forum, and while adapting our Git workflow to use submodules might be an easy change for us active members/contributors, it isn't for them -- so we have to keep those use cases in mind. We also have to consider that using git-submodule is a breaking change for everyone that has a more or less automated workflow (bash/batch scripts that update and build SFML).

______
* git submodules also need special commands when pulling SFML, not just for the initial clone. This is another case where doing a normal git pull will leave dependencies without update, i.e. another source of error.

[Jonny]

Subtree looks like a reasonable compromise, although information on it is a little thin spread.

We also have to consider that using git-submodule is a breaking change for everyone that has a more or less automated workflow (bash/batch scripts that update and build SFML).

It doesn't have to be - the submodules can be cloned/updated as part of the cmake script

Ultimately I don't mind too much, I'm just keen to see a decision made, if you have a better suggestion than a poll to get this done that's absolutely fine by me.

[Vauteck]

What about repo tool (https://gerrit.googlesource.com/git-repo/)? Google use this to manage all the 10's of external repositories dependancies of the Android open source project. It seems to be working pretty okay for them.
I've never used the tool myself but I've heard it does a better job than submodules at dealing with multiple git repo's.
Here's a review of the tool (sorry for non french speakers) : http://www.yoannsculo.fr/git-repo-outil-gestion-multiples-repositories-arracher-cheveux/

[Jonny]

Personally I don't think it's a good idea to add another requirement/dependency like that just to manage our dependencies

[Nexus]

I also think we shouldn't overdo it. The original problem of this thread were binaries for dependencies, which need to be maintained by SFML, and where source code would have some advantages.

[JORDANN]

thank you for sharing the  dependencies of C libraries, and advantages of not recompiled for each compiler. 

[Elias Daler]

Found one more interesting case against using git submodules - when you do release on GitHub, zip with source doesn't include ".git" subdirectory, so you can't checkout 3rd party lib sources. So yeah, you get "source dir" which you can't even build because submodules are not checkout out there.

[Jonny]

Don't suppose there's been any decision either way on this?

[markand]

I also vote for the exclusion of the bundled libraries (either in binary or source form). It's not the purpose of SFML to do this on behalf of the SFML user.

Also, it's just to complex to bring because of:

• different toolchain versions
• different architectures
• different compile options
• and so on

This is the responsability of the user to provide its dependencies, not SFML one. Less code, less build, less problems :-).

Qt did ship bundled libraries as well but they eventually decided to remove in Qt 6.