Development of GZDoom with GitHub

[MatrixCL]

I might be helping out here in there with RFC's on GZDoom. Though I am a web developer (full stack, but still). An application like this is quite something else, so my contributions will probably be limited to tweaks here and there, as I don't think I'll invest in figuring out how the whole application works in general. Unless one of the developers here is willing to give me a tutorial.

I assume I won't get the rights to make git commits myself any time soon (nor should I), but can only do pull requests. Not too sure how that works, but I'll figure it out. In whatever git project I've been working on, I've always had full rights.

I followed the procedure in the wiki and was able to compile and run it on the first try. Yay!

But now I don't really understand how the procedure works for actual development. With the git repository, I created a Visual Studio project using CMake. Then I can make changes, compile, and see the results. However, those alterations are then not on the repository, but on the VS project, so I can't commit that to GitHub. Therefore I should either copy the changes from the project to the repository dir, or only make changes in the repository dir and then create a VS project and compile every time I change something, which is way too impractical and cumbersome. Am I missing something here? Or is this simply the burden we developers have to bear for supporting different platforms with shared code?

[dpJudas]

Fork the project on github. Make your own changes in a branch in that fork. Push it to github in your fork. Go to github's website and select you want to create a pull request for the branch. There you can select you want to send the pull request to the gzdoom upstream project.

[drfrag]

You need to install Git and optionally TortoiseGit and clone the repository in your hard drive too. And you create the VS project in that folder to test and commit your changes locally first. You usually rename origin as upstream and your fork is then origin, you can rename your fork too to something else than gzdoom (i did not).

[MatrixCL]

My question was actually different. I thought the code of the VS solution and git repository were separate things. But now I see they are actually the same, even when the solution is on an entirely different location. So I can just make changes in the VS solution, see if it works, and then commit the code change straight away instead of having to make those changes in the repository as well. I had never heard of CMake before, let alone used it, so that's why I asked.

But I didn't know about forking and creating pull requests from there. So thanks for that (rather vital) info. I'm ready to fly.

[Graf Zahl]

The entire system would be monumentally useless if it didn't work seamlessly, wouldn't you think?
CMake is convenient because it allows maintaining just one project for all platforms as opposed to separate ones for each that can easily disagree on their content.

[Rachael]

CMake is convenient as long as you are only adding and removing files, or if you are an end-user.

It's not quite so convenient when you have to redesign your project file from scratch...

[Graf Zahl]

If you need to do that, any IDE is just as bad because it is impossible to remember and properly set every single option. And unlike CMake you cannot easily build upon an existing file but really have to do it from scratch. I often ended up editing the project files in a text editor. With Visual Studio which uses XML-based formats that's at least doable, but with Apple's XCode projects it stops being fun quickly - they are very much unmaintainable with their endless list of cross-references and redundant definitions of several items.

If a project gets complex in CMake it is very likely you'll never be able to get the same level of functionality natively.