Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CMake support? #194

Open
kangsheng89 opened this issue Apr 15, 2021 · 11 comments
Open

CMake support? #194

kangsheng89 opened this issue Apr 15, 2021 · 11 comments

Comments

@kangsheng89
Copy link

is there any plan for offcial cmake support for the-forge?

https://github.com/DeanoC/The-Forge/blob/master/CMakeLists.txt

@cboiangiu
Copy link

I am currently trying to put together support for cmake with https://github.com/cboiangiu/The-Forge.cmake. I am using https://github.com/widberg/bgfx.cmake as a guide. Ideally I wish to build The-Forge as a package and then include the lib as a framework.
Also working on https://github.com/cboiangiu/the-forge-starter to implement the lib with cmake support and draw a simple cube, while keeping the useful interfaces such as IApp (like they are used in the Unit Tests). The starter is based on https://github.com/pr0g/sdl-bgfx-imgui-starter.

@kangsheng89
Copy link
Author

Yes i totally agree with package it as lib. with cmake move, we also can consider using conan/vcpkg. By doing so, it will make the opensource community to adopt this framework

@mgood7123
Copy link

mgood7123 commented Jun 28, 2021

I am currently trying to put together support for cmake with https://github.com/cboiangiu/The-Forge.cmake. I am using https://github.com/widberg/bgfx.cmake as a guide. Ideally I wish to build The-Forge as a package and then include the lib as a framework.
Also working on https://github.com/cboiangiu/the-forge-starter to implement the lib with cmake support and draw a simple cube, while keeping the useful interfaces such as IApp (like they are used in the Unit Tests). The starter is based on https://github.com/pr0g/sdl-bgfx-imgui-starter.

this would also allow it to "just be used" with other IDE's that have support for cmake (or even simply via cmake itself like make project (fictional makefile target) which would call cmake)

@THISISAGOODNAME
Copy link

https://github.com/CU-Production/The-Forge-CMake
You can build The-Forge first, and then use it as a library.

@Geenz
Copy link

Geenz commented Feb 24, 2022

https://github.com/Geenz/TheForgeTheCmake
This is my attempt at it. It's fairly incomplete - but stuff like dynamic linking is there. I'm working on adding unit tests and the like.

@JonahGoldsmith
Copy link

I have a working version for the newest update of The-Forge!
https://github.com/JonahGoldsmith/The-Forge-CMake
This Works on Windows Only but will work on MACOS and IOS in the next few days!
The Test Project Shows how to copy DLL's and Run the Shader Compiler just like the VS Projects Do!

@jochumdev
Copy link

I've made:

TheForgeCMake reflect's the UbuntuCodeLite/*.project files.

@Caellian
Copy link

Caellian commented May 12, 2024

I agree, but this has been previously discussed in #158 and the issue is that CMake supports too much so the tests wouldn't cover all the supported targets.

Not sure why simply checking MSVC_VERSION isn't an option as CMake could be made to throw errors if unsupported target is used. It's up to maintainers though and it seems they prefer using .sln files instead.

On a practical side of things, switching is almost certainly a cost that wouldn't be directly beneficial to them and if they're not familiar with CMake it just adds additional complexity to maintaining their .sln, so I don't believe they'd be willing to incur the cost of switching and maintaining even if someone provided a complete solution.

@cboiangiu
Copy link

cboiangiu commented Jun 24, 2024

I agree, but this has been previously discussed in #158 and the issue is that CMake supports too much so the tests wouldn't cover all the supported targets.

Not sure why simply checking MSVC_VERSION isn't an option as CMake could be made to throw errors if unsupported target is used. It's up to maintainers though and it seems they prefer using .sln files instead.

On a practical side of things, switching is almost certainly a cost that wouldn't be directly beneficial to them and if they're not familiar with CMake it just adds additional complexity to maintaining their .sln, so I don't believe they'd be willing to incur the cost of switching and maintaining even if someone provided a complete solution.

Wouldn't adding proper CMake support allow for easy generation of the current .slns though? It's just that you focus on maintaining the CMake, instead, for better or for worse.

@cboiangiu
Copy link

cboiangiu commented Jun 24, 2024

I do however support the idea of having a cross-platform template project similar to this with separate CMake support as a starting point. This would be best maintained separately from the current unit tests as to not disrupt the current pipelines and processes. Ideally this could be later merged here maybe, as it would be easier to maintain breaking changes or additions to the CMake project.
The template project using the CMake project across different platforms could also be seen as just another unit test.

@Caellian
Copy link

Wouldn't adding proper CMake support allow for easy generation of the current .slns though? It's just that you focus on maintaining the CMake, instead, for better or for worse.

Yes and no. Differences start to show with complex configurations (e.g. game engines). A generator will never satisfy all requirements in all environments, which is why they don't want to use it.

For the same reason, you might be better off setting up your own configuration with specialized dependencies, which I'm guessing they're doing for their clients.

  • Many of used dependencies aren't what I'd personally pick when starting a new project for several different reasons (e.g. Lua vs LuaJIT, scheduling, etc.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants