godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
91.16k stars 21.2k forks source link

Remove "thirdparty" software from repo #7734

Closed JohnMH closed 7 years ago

JohnMH commented 7 years ago

Remove software that has just been thrown into the directory "thirdparty" and instead mention that software should be installed through the system's package manager. I would suggest listing all dependencies.

reduz commented 7 years ago

Haha, good joke. I wonder if you ever considered that other operating systems other than Linux distros exist..

JohnMH commented 7 years ago

I have, and I never mentioned anything about "Linux distros". Package management tools exist everywhere, and perhaps Windows is one exception to this (though package management tools do exist, they're not very popular).

Still, third party software should not be included in the main repository, and really shouldn't be in any repository that is part of Godot.

reduz commented 7 years ago

Let me give you a list of all the platforms which do not have a native and official package manager (with the dependencies we require):

List of supported platforms that do:

vichug commented 7 years ago

"third party software should not be included in the main repository, and really shouldn't be in any repository that is part of Godot."

Why ?

JohnMH commented 7 years ago

Because you do have a fair point on the lack of package management on systems, I will address each of the platforms you have listed.

Linux Desktop is not a platform.

Windows has about 3 different package managers, and I think it has one built in now (could be wrong on that). Having a dependency tree would be a great idea, in MinGW or cygwin, whichever you choose to use to build the project.

OS X has Homebrew, which is the only way I can think that anybody would install Godot. On OS X, you would have to install gcc and dependencies through Homebrew anyway, so I don't know why they're bundled here.

I have not developed anything for iOS, looks like it'd be a pain, and I can offer no advice here other than to say not to have all dependencies in the repo for the engine itself. Perhaps go argue with Apple about getting libraries set up on the app store as 'dependency projects'.

The same applies for Android, but I will say that with Android it's a slightly better situation, because you can just make users install a library package (but currently that's only automatically supported with F-Droid, I don't think Google Play has that feature yet).

For Emscripten, that's another issue. You'd have to compile them all yourself here and get them all set up in some custom toolchain, but I don't think a lot of people really use Emscripten anyway. It's a pain, and I can understand avoiding it.

I don't know what UWP is, and I don't know what BB10 is. With that in mind, I'm going to say that they're probably incredibly irrelevant and shouldn't even be considered as platforms.

Debian, Fedora, NixOS, Gentoo, Ubuntu, Linux Mint and other operating systems using the GNU userland and the Linux kernel provide these packages natively and there's absolutely no reason for the project to use specific bundled versions of them.

FreeBSD and other BSD systems also have package managers and similar mechanisms to install dependencies.

I will say that Fedora has done some amazing work to modularize packages to be cross compiled for targets like Windows and Emscripten. All of the dependencies of Godot are currently available in Fedora repos for cross compilation for Windows.

Whether the systems have package management or not isn't really an issue though, for those platforms (iOS, Android, Emscripten) it would be incredibly simple for the Godot project to provide a repository with the current contents of the 'thirdparty' directory, as that would only be useful for developers.

Even Microsoft is trying to do something now about duplicated libraries and binaries sitting around a Windows system, even if they are going about it in an entirely misguided manner. If Microsoft acknowledges that this is an issue, I don't think I need to explain exactly how this is detrimental to the project. Maintainers of the godot repository and developers building Godot shouldn't need to worry about dependencies and updating dependencies to the latest version, but rather just building and testing Godot with the versions provided by their system.

reduz commented 7 years ago

I hope you do realize that the approach you propose not only gives zero benefits to users, but also makes Godot much harder to compile.

Plenty of users download and compile Godot themsevles for many platforms, and appreciate how easy it is to compile (in comparison to most open source software of this kind).

There is simply no intention o make things more difficult for them, forcing them to install and conpile all dependencies manually. We take pride in the way things currently work.

Also, if you use Linux, you can specify system version for many of the libraries.

On Feb 5, 2017 9:22 PM, "John M. Harris, Jr." notifications@github.com wrote:

Because you do have a fair point on the lack of package management on systems, I will address each of the platforms you have listed.

Linux Desktop is not a platform.

Windows has about 3 different package managers, and I think it has one built in now (could be wrong on that). Having a dependency tree would be a great idea, in MinGW or cygwin, whichever you choose to use to build the project.

OS X has Homebrew, which is the only way I can think that anybody would install Godot. On OS X, you would have to install gcc and dependencies through Homebrew anyway, so I don't know why they're bundled here.

I have not developed anything for iOS, looks like it'd be a pain, and I can offer no advice here other than to say not to have all dependencies in the repo for the engine itself. Perhaps go argue with Apple about getting libraries set up on the app store as 'dependency projects'.

The same applies for Android, but I will say that with Android it's a slightly better situation, because you can just make users install a library package (but currently that's only automatically supported with F-Droid, I don't think Google Play has that feature yet).

For Emscripten, that's another issue. You'd have to compile them all yourself here and get them all set up in some custom toolchain, but I don't think a lot of people really use Emscripten anyway. It's a pain, and I can understand avoiding it.

I don't know what UWP is, and I don't know what BB10 is. With that in mind, I'm going to say that they're probably incredibly irrelevant and shouldn't even be considered as platforms.

Debian, Fedora, NixOS, Gentoo, Ubuntu, Linux Mint and other operating systems using the GNU userland and the Linux kernel provide these packages natively and there's absolutely no reason for the project to use specific bundled versions of them.

FreeBSD and other BSD systems also have package managers and similar mechanisms to install dependencies.

I will say that Fedora has done some amazing work to modularize packages to be cross compiled for targets like Windows and Emscripten. All of the dependencies of Godot are currently available in Fedora repos for cross compilation for Windows.

Whether the systems have package management or not isn't really an issue though, for those platforms (iOS, Android, Emscripten) it would be incredibly simple for the Godot project to provide a repository with the current contents of the 'thirdparty' directory, as that would only be useful for developers.

Even Microsoft is trying to do something now about duplicated libraries and binaries sitting around a Windows system, even if they are going about it in an entirely misguided manner. If Microsoft acknowledges that this is an issue, I don't think I need to explain exactly how this is detrimental to the project. Maintainers of the godot repository and developers building Godot shouldn't need to worry about dependencies and updating dependencies to the latest version, but rather just building and testing Godot with the versions provided by their system.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/7734#issuecomment-277562390, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2ybJvG-IKVtaLA9cnNtj-AKi-tEzks5rZme3gaJpZM4L3rHa .

vnen commented 7 years ago

@JohnMHarrisJr So you suggest we drop the bundled third party dependencies and make building Godot incredibly difficult for most target platforms?

If you look closely, things haven't "just been thrown into the directory 'thirdparty'", they are integrated with the buildsystem and assured to be compatible with Godot, so it's not broken when the third party decides to release a compatibility-breaking version. Some of those were changed to build fine along with Godot for every platform.

Right now building Godot is just clone it and SCons it. You suggest it to be clone it, build every dependency for the target platforms (fixing them along the way, depending on the target), configure environment variables to point to their paths and then SCons it. I'd rather stay with the former.

JohnMH commented 7 years ago

Users benefit by not having duplicate libraries and binaries laying around. Godot has taken a lazy and inconsiderate approach to this particular issue. The current system being 'easy for users' is just an excuse for the current system, and doesn't actually hold any value.

My suggestion makes Godot no harder to compile, but does require the current build system to be altered. With my suggestion, dependencies are handled either by a package manager or by an external repository from this and are built only as needed.

The process to build Godot on most systems would be this:

  1. Clone
  2. Build with no environmental variable nonsense
reduz commented 7 years ago

Proposal rejected.

JohnMH commented 7 years ago

Still, there should at least be some discussion on this topic, rather than just outright rejection. There are many issues with the way this is currently handled. Bundling dependencies is a horrible practice, and to see it used in this project is really weird.

vnen commented 7 years ago

We can have a discussion but you have to propose an actual solution. For instance, you gave no solution for the aforementioned platforms:

So unless you have a real solution to those platforms, I agree with @reduz that this proposal cannot be done.

Moving the thirdparty folder to another repository is an unneeded complication and requires more maintenance than the current solution.

kpiorno commented 7 years ago

May be some code could be added to scons files to do what you are proposing. But removing "thirdparty" software from repo will killing one of the best feature that Godot has: "Easy Compiling" :).

JohnMH commented 7 years ago

Bundling software adds several issues that you don't seem to be considering: Security issues with dependencies, duplicated binaries and libraries.

Easy compiling is not a feature of this project, and I can vouch for this after packaging Godot.

On February 5, 2017 8:29:21 PM EST, Karel Piorno Charchabal notifications@github.com wrote:

May be some code could be added to scons files to do what you are proposing. But removing "thirdparty" software from repo will killing one of the best feature that Godot has: "Easy Compiling" :).

-- John M. Harris, Jr. PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

JohnMH commented 7 years ago

I did not dismiss Emscripten, or any of the other platforms mentioned. For those, the thirdparty repo might be fine.

I didn't realize you were using Visual Studio. I have no idea how that situation would work, but you can just not use that proprietary garbage.

You can easily just use Fedora or another distro to build for Windows, cross compiling with MinGW.

On February 5, 2017 8:17:27 PM EST, George Marques notifications@github.com wrote:

We can have a discussion but you have to propose an actual solution. For instance, you gave no solution for the aforementioned platforms:

  • You said iOS can't do it and Apple should resolve it (good luck with that).
  • You said Google Play can't do it (where the majority of Godot users expect to publish Android apps).
  • You dismiss Emscripten (the way we use to build for web)
  • You dismiss UWP (which stands for Universal Windows Apps, making Godot available in Windows Phone and Xbox One).
  • Windows has no built-in package manager and if you mean Nuget (which comes with Visual Studio) I'm pretty sure it does not have all the needed dependencies.

So unless you have a real solution to those platforms, I agree with @reduz that this proposal cannot be done.

Moving the thirdparty folder to another repository is an unneeded complication and requires more maintenance than the current solution.

-- John M. Harris, Jr. PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

reduz commented 7 years ago

You are wasting your time, ease of compilation for all platforms is top priority. Packaging is at the bottom.

On Feb 5, 2017 23:07, "John M. Harris, Jr." notifications@github.com wrote:

I did not dismiss Emscripten, or any of the other platforms mentioned. For those, the thirdparty repo might be fine.

I didn't realize you were using Visual Studio. I have no idea how that situation would work, but you can just not use that proprietary garbage.

You can easily just use Fedora or another distro to build for Windows, cross compiling with MinGW.

On February 5, 2017 8:17:27 PM EST, George Marques < notifications@github.com> wrote:

We can have a discussion but you have to propose an actual solution. For instance, you gave no solution for the aforementioned platforms:

  • You said iOS can't do it and Apple should resolve it (good luck with that).
  • You said Google Play can't do it (where the majority of Godot users expect to publish Android apps).
  • You dismiss Emscripten (the way we use to build for web)
  • You dismiss UWP (which stands for Universal Windows Apps, making Godot available in Windows Phone and Xbox One).
  • Windows has no built-in package manager and if you mean Nuget (which comes with Visual Studio) I'm pretty sure it does not have all the needed dependencies.

So unless you have a real solution to those platforms, I agree with @reduz that this proposal cannot be done.

Moving the thirdparty folder to another repository is an unneeded complication and requires more maintenance than the current solution.

-- John M. Harris, Jr. PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/7734#issuecomment-277571142, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z2zkNJaVZUTIhAmFQiUkdA2dNJT_Fks5rZoB5gaJpZM4L3rHa .

JohnMH commented 7 years ago

It's easy to compile if I can 'apt-get install build-essential dep1 dep2', not if I have to clone the repo and wait for all of the third party stuff to download with old versions the rest of my system can't use with all ot the security issues and duplication involved.

On February 5, 2017 9:23:10 PM EST, Juan Linietsky notifications@github.com wrote:

You are wasting your time, ease of compilation for all platforms is top priority. Packaging is at the bottom.

On Feb 5, 2017 23:07, "John M. Harris, Jr." notifications@github.com wrote:

I did not dismiss Emscripten, or any of the other platforms mentioned. For those, the thirdparty repo might be fine.

I didn't realize you were using Visual Studio. I have no idea how that situation would work, but you can just not use that proprietary garbage.

You can easily just use Fedora or another distro to build for Windows, cross compiling with MinGW.

On February 5, 2017 8:17:27 PM EST, George Marques < notifications@github.com> wrote:

We can have a discussion but you have to propose an actual solution. For instance, you gave no solution for the aforementioned platforms:

  • You said iOS can't do it and Apple should resolve it (good luck with that).
  • You said Google Play can't do it (where the majority of Godot users expect to publish Android apps).
  • You dismiss Emscripten (the way we use to build for web)
  • You dismiss UWP (which stands for Universal Windows Apps, making Godot available in Windows Phone and Xbox One).
  • Windows has no built-in package manager and if you mean Nuget (which comes with Visual Studio) I'm pretty sure it does not have all the needed dependencies.

So unless you have a real solution to those platforms, I agree with @reduz that this proposal cannot be done.

Moving the thirdparty folder to another repository is an unneeded complication and requires more maintenance than the current solution.

-- John M. Harris, Jr. PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub

https://github.com/godotengine/godot/issues/7734#issuecomment-277571142, or mute the thread

https://github.com/notifications/unsubscribe-auth/AF-Z2zkNJaVZUTIhAmFQiUkdA2dNJT_Fks5rZoB5gaJpZM4L3rHa .

-- John M. Harris, Jr. PGP Key: f2ea233509f192f98464c2e94f8f03c64bb38ffd

Sent from my Android device. Please excuse my brevity.

reduz commented 7 years ago

locked topic, discussing this further is pointless, as we are not going to change how we manage third party software.

akien-mga commented 7 years ago

Please do some research before asking us to do pointless things like removing the thirdparty repo for the sake of purity of the holy compiled symbols.

You can already configure the build on the X11 platform (basically all platforms you listed as having a package manager run X11) to disable almost all thirdparty libraries and link shared libraries instead. And yes, then you can just rm -rf those folders.

I'm a packager for a GNU/Linux distro (see e.g. my godot package), I know what unbundling means, what are its stakes and I can assure you that Godot is way more packaging friendly than most other FOSS projects of its size.