Skip to content

Conversation

st0rmbtw
Copy link
Contributor

@st0rmbtw st0rmbtw commented Aug 20, 2025

Useful when the user wants to use third party windowing library like GLFW.

@LukasBanana
Copy link
Owner

How is the windowing system in LLGL interfering with external libraries such as GLFW? LLGL is designed to have a simple and easy to use windowing system as a fallback while also allowing to hook up any other thirdparty library for that purpose. Is this causing compilation trouble or are there any binary size concerns?
If not then I think this adds unnecessary complexity. All the preprocessor conditionals in GL for instance are a necessity to share as much code between the different profiles that cannot be compiled into one binary because they are mutually exclusive. But I don't quite see this necessity for the windowing system.
Maybe I'm missing something but the rationale for this PR should already be valid without this change.

@st0rmbtw
Copy link
Contributor Author

st0rmbtw commented Aug 21, 2025

Is this causing compilation trouble or are there any binary size concerns?

No, it's not.

I just thought that if you are using an external windowing library then why would you include the code you don't use into the binary (specifically LLGL windowing code).

For example, there is a game engine called bevy that written in Rust and it has a fully modular structure. The user can add or remove unnecessary features like windowing, rendering system, etc. So, I thought it would be nice to have something like that here too. But, it seems that people don't do that kind of thing in C++.

Feel free to close this PR btw.

@LukasBanana
Copy link
Owner

For example, there is a game engine called bevy that written in Rust and it has a fully modular structure.

I can see the benefit of that and I'm trying to keep LLGL modular to an extent, like with the backends for instance that you can simply add or remove without recompiling the libraries. But the nature of the C preprocessor limits the modularity of this approach in C++. It only adds a lot of preprocessor conditions which already make it harder to follow, which is also why I'm trying to separate platform specific code into separate files and subfolders instead of having many #if _WIN32-style blocks.

I think we can close this. If we wanted to come back to this feature, we should first move more platform code that is specific to the windowing system into isolated files. Right now, it's just as expected to be included as a fallback when no thirdparty windowing system is hooked up.

@LukasBanana LukasBanana added the feature request Requested features and TODO lists label Aug 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Requested features and TODO lists
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants