Ah, I can help here!
The OpenGL (and sometimes Vulkan) API wrapper/loader "glad" is intended
to be custom generated for the project, since you select the extensions
you want at that time. It's actually generated by a Python module, and
does not have a single canonical set of C sources/headers. The project
you linked is just one person who generated it for their own use (the
forge maintainer), and put their own copyright and license on it
(incorrectly!).
The real upstream is https://glad.dav1d.de/ and
https://github.com/Dav1dde/glad
There are lots of projects that use it to generate minimal
wrappers/loaders for opengl (I maintain some). Just try a code search
for one of the symbols in it,
e.g. https://codesearch.debian.net/search?q=GLAD_GL_VERSION_1_0&literal=1&perpkg=1
Honestly it kind of breaks/defeats its purpose if you try to package it
separately. It definitely is not supposed to be a separately-
distributed shared library. In my opinion it would be wasted effort to
do so. Nobody would accept the patches upstream because that's not how
glad works.
I recommend we take none of the possible actions listed, and instead
use vendored glad where projects need it.
In the specific case of "forge", since it looks like upstream is using
effectively "ExternalProject" via a backported version of the
"FetchContent" module to try to download at build time, I see two
possible options.
- Use multiple upstream tarballs
- Add the dependency in a patch: needs only approx three files (a
header, implementation, and CMake script).
Either way, once the generated version of glad suitable for forge is
available, we should be able to just pass:
-DFETCHCONTENT_SOURCE_DIR_=extern/fg_glad-src \
-DFETCHCONTENT_FULLY_DISCONNECTED=TRUE
or similar to CMake to teach it where the glad source is without
downloading. It looks like forge has some mechanism and preferred
location for these files on its own too [1] (that's how I picked the
directory above). However, we can likely use the standard CMake
module's override facilities, which makes for easier maintenance.
Hope this helps!
Rylie Pavlik
[1]:
https://salsa.debian.org/science-team/forge/-/blob/master/CMakeModules/ForgeConfigureDepsVars.cmake#L66-91
On Wed, 2025-01-08 at 17:56 +0100, Andreas Tille wrote:
> Hi,
>
> as it was found and noted as todo in changelog of forge we need glad
> as a pre-dependency[1]. Possible actions are:
>
> 1. Revert forge to latest version that does not need glad
> 2. Package glad[2]
> 3. Remove forge from Debian
>
> What do you think?
>
> Kind regards
> Andreas.
>
>
> [1]
> https://salsa.debian.org/science-team/forge/-/blob/master/debian/changelog?ref_type=heads
> [2] https://github.com/arrayfire/glad
>
>
Attachment:
signature.asc
Description: This is a digitally signed message part