Commit Graph

8 Commits

Author SHA1 Message Date
Rémi Verschelde 9e4315bb50
Style: Harmonize header includes in platform ports
This applies our existing style guide, and adds a new rule to that style
guide for modular components such as platform ports and modules:

Includes from the platform port or module should be included with relative
paths (relative to the root folder of the modular component, e.g.
`platform/linuxbsd/`), in their own section before Godot's "core" includes.

The `api` and `export` subfolders also need to be handled as self-contained
(and thus use relative paths for their "local" includes) as they are all
compiled for each editor platform, without necessarily having the api/export
matching platform folder in the include path.
E.g. the Linux editor build will compile `platform/android/{api,export}/*.cpp`
and those need to use relative includes for it to work.
2023-06-08 15:19:19 +02:00
Ninni Pipping 71ee65dc57 Enable shadow warnings and fix raised errors 2023-05-11 16:00:59 +02:00
bruvzg dd068794c3
[Linux] Make SO wrapper usage optional. 2023-02-16 16:38:47 +02:00
Rémi Verschelde d95794ec8a
One Copyright Update to rule them all
As many open source projects have started doing it, we're removing the
current year from the copyright notice, so that we don't need to bump
it every year.

It seems like only the first year of publication is technically
relevant for copyright notices, and even that seems to be something
that many companies stopped listing altogether (in a version controlled
codebase, the commits are a much better source of date of publication
than a hardcoded copyright statement).

We also now list Godot Engine contributors first as we're collectively
the current maintainers of the project, and we clarify that the
"exclusive" copyright of the co-founders covers the timespan before
opensourcing (their further contributions are included as part of Godot
Engine contributors).

Also fixed "cf." Frenchism - it's meant as "refer to / see".
2023-01-05 13:25:55 +01:00
Riteo 2dd5a792bb Load X11 dynamically
The loaders have been generated through hpvb's dynload-wrapper, although
they had to be heavily handpatched to workaround some already reported
issues with it. I added a note to each generated file to account for
that.

As GLAD uses X11 stuff directly, I had to define the GLAD_GLX_NO_X11
macro to not let do it that, and handle myself the display loading and
screen handling part myself, which wasn't that hard but it's still
something worth saying.

I plan to improve greatly the X11 backend (including this aspect) but,
as the release isn't that far and I'm also working on the Wayland
backend, this will do for now, I hope.
2022-12-03 19:23:43 +01:00
Riteo Siuga dc2919d57b Load GLX dynamically with GLAD
This is accomplished through the addition of a GLAD GLX loader in the
`thirdparty` directory.

This is another step towards a nice Wayland/X11 interoperation.
2022-11-15 13:55:30 +01:00
Abdulrahman Al Zeidi 5860f81c18 Fix static object destructors being called on gpu selection with X11 2022-11-07 12:08:52 +00:00
Riteo 593c571d6a linuxbsd: move all X11 stuff in its own directory
This allows implementing `DisplayServer`s like Wayland without making a
mess in the source tree.
2022-11-02 20:48:46 +01:00