| Summary: | Ideas for SDL 3 | ||
|---|---|---|---|
| Product: | SDL | Reporter: | David Demelier <markand> |
| Component: | *don't know* | Assignee: | Ryan C. Gordon <icculus> |
| Status: | ASSIGNED --- | QA Contact: | Sam Lantinga <slouken> |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | daegon.dhsk, dll, jhasse, sdl-bugzilla |
| Version: | don't know | ||
| Hardware: | All | ||
| OS: | All | ||
|
Description
David Demelier
2020-01-22 15:55:25 UTC
I agree with most of this feedback, and like the satellite library naming suggestions, thanks! Some comments on the build system: Not all platforms have CMake, and many developers don't have CMake installed. Windows developers should be able to use Visual Studio, Mac developers should be able to use Xcode. I should be able to use autoconf. :) I'm fine with CMake being the recommended build environment, and even stripping out support for non-UNIX platforms from it, but I've run into enough problems with it over the years that I don't use CMake. Also, note that the official SDL windows binaries are built on Mac using mingw64, to integrate with build scripts and avoid C runtime dependencies, and that currently requires autotools. > # Simplify development process
I think there should be more discussion on just moving the center of development to github / git. I'm aware that this has been proposed by many people over the years, but I feel it hasn't gotten the proper attention it needs.
Github or at least git, would make it much easier for people to contribute to the development of SDL.
(In reply to daegon.dhsk from comment #2) > Github or at least git, would make it much easier for people to contribute > to the development of SDL. This is a hard no from me, both to GitHub and git itself. --ryan. (In reply to Ryan C. Gordon from comment #3) > (In reply to daegon.dhsk from comment #2) > > Github or at least git, would make it much easier for people to contribute > > to the development of SDL. > > This is a hard no from me, both to GitHub and git itself. > > --ryan. Could we get some details on the background? (In reply to daegon.dhsk from comment #4) > Could we get some details on the background? Even if I didn't personally think git is a lousy system, Mercurial is working fine for us and changing it just introduces unnecessary friction. As for GitHub: we have been burned by cloud providers several times over the past 20 years, and have spent significant effort engineering our infrastructure so we own all of it. Becoming reliant on an unnecessary for-profit company for the most crucial piece of our workflow is not something we're willing to do. --ryan. (In reply to daegon.dhsk from comment #2) > > # Simplify development process > > I think there should be more discussion on just moving the center of > development to github / git. I'm aware that this has been proposed by many > people over the years, but I feel it hasn't gotten the proper attention it > needs. > > Github or at least git, would make it much easier for people to contribute > to the development of SDL. I can't understand this hype to request people to move to Git. Git is by far much more complicated than Mercurial so I'd like to know what's “easier” for you to contribute. If by easier you mean that you can send a pull request, please not that sending a patch is by far much easier: hg clone http://hg.libsdl.org/SDL && cd SDL vim hg ci hg export OR hg email That's it. You can't come to a project and ask them to change their tooling, this is a subjective material. I don't like Git but I don't ask projects to move from Git to Mercurial. I don't like meson and I don't request projects that use meson to switch to CMake. I can go for a while. The only way we could improve the contributing process for SDL is to provide a detailed documentation because for now there are not that much. So some people send emails and some tasks on bugzilla. We need a unified, detailed process. That's it. (In reply to David Demelier from comment #6) > If by easier you mean that you can send a pull request, please not that > sending a patch is by far much easier: > > hg clone http://hg.libsdl.org/SDL && cd SDL > vim > hg ci > hg export OR hg email > > That's it. Wait, vim is now part of the easy route?! (and I like vim, for some things at least) ;-) In all seriousness, a move to git sounds ok to me, though not one to GitHub and its partially-closed nature. I find git's overall ecosystem to be *MUCH* nicer than Mercurial's (enough that I am willing to argue that Mercurial isn't always the "easiest" option, not any more at least), and would probably welcome a move to git repos. I have, within the past few years, lost Mercurial support in some valuable-to-me tools (BitBucket, especially), and finding good, alternative tooling hasn't always been easy. As for the initial suggestions, I'm in favor of a lot of it! I especially like the idea of iterating on SDL's function names. Having a scheme along the lines of SDL_<subsystem><action> seems very helpful with regards to editor auto-completion. I'd like to add one suggestion with regards to naming: include the major version number in the prefix. I.e. SDL3.h, SDL3_RenderSetDrawColor, etc. It would make SDL 3.x detection be a matter of finding a header, rather than finding a header and parsing it, which might not always be possible (with C++'s __has_include, for example). It would also help make it possible to distinguish SDL 1.x and 2.x code from 3.x code, which I could see helping if and when porting stuff to 3.x. Regarding dropping WinRT, it's my understanding that Xbox One still requires using those APIs. Unless that changes, I think removing that support would be bad (though, that platform's SDL code could definitely use some improvement, with at least some pruning of older, WinRT SDK support). Regarding build-systems, I like the idea of better CMake integration, but I would like to see file-globbing of SDL's src directory be an option, too, at least for platforms where this is possible. (One of these days, I should finish my support for this. I've had prototypes working on Apple-platforms, as well as Windows, at one point or another). As for including satellite libraries in SDL-proper, this makes me leery as it seems like it would introduce a lot of additional dependencies in SDL, which is already inherently complex due to the number of platforms it supports. Having naming changes within them does sound nice, and perhaps possible without needing to include them in SDL itself. > Windows developers should be able to use Visual Studio, Mac developers should be able to use Xcode.
Both can be generated using CMake :)
> > Windows developers should be able to use Visual Studio, Mac developers should be able to use Xcode.
>
> Both can be generated using CMake :)
I have only tried a few times but those projects all didn't generate a working xcode project. No idea if this is a problem with their CMake files but if you have to work extensively on the Xcode project file each time you generate it from code, then it is no good, IMO worse than a partially working included one.
So, when I see there is only CMake, I try to find whether someone else already built an Xcode project file or just turn away and don't bother.
Generation of the unix stuff generally works though.
> I have only tried a few times but those projects all didn't generate a working xcode project.
What do you mean by "those projects"?
> > I have only tried a few times but those projects all didn't generate a working xcode project.
>
> What do you mean by "those projects"?
the projects that had only Cmake and I tried to generate the Xcode project with
Ah I see. I think some projects don't take Xcode into account and use some unidiomatic CMake constructs that break it. It is definitely possible though and works great in my projects. It's a good idea to add a CI job which generates and builds with `-GXcode`. |