That explains that and why there's no widespread CMake usage in the Orbiter community, Orbiter is of course a Windows-native application. And it has been my feeling that most programmers around here are more familiar with code development in Windows.
It is what Microsoft calls Windows Development in C++ today. Technology progresses. And it is not too bad to save some extra work with proper automatisation. Its not like we need to reinvent the wheel again today.
https://github.com/Microsoft/vcpkg/
https://cmake.org/
Also, we have quite many Linux veterans here, that sure know CMake and its alternatives in the Linux world.
In theory, we could even separate the development workspace from the Orbiter installation and no longer need to install Orbiter into the SSU working copy. Would have the advantage that its easier to catch missing files, since everything that is not on the list for CMake would not be copied into the testing installation of Orbiter then - and old files automatically removed.
I had a test project on my old Notebook, I will try recovering it for some examples. Its no black magic, automatically producing a NSIS Installer package from an Orbiter project is quite easy.
---------- Post added at 13:41 ---------- Previous post was at 10:03 ----------
About the "There must be room for disagreements about things with everything blowing up every time":
I don't see that the project is in any state for allowing careless handling without everything blowing up. We have tons of bugs, lots of historic ballast and our processes are at best at CMMI Level 0. It had been bad in the past, but never THIS bad. From a pure engineering point of view, the project has a near-death experience.
Next, there is the social interaction. Not respecting responsibilities and maintaining transparence is one aspect.
I admit that I should have been communicating clearer in advance, that I consider using the currently available compiler toolchain is standard, not some past version, unless there is a good reason for that.
But that is no excuse to be disrespectful towards others for defending the old compiler version. That is not about language barriers, but about getting uncomfortably personal for discussing technical problems.
Its a freetime project. Nobody HAS to be here. We all should have a commitment to the project, but that is not infinite or essential. Especially, I don't think anybody should commit himself more than really needed.
So, how to get out of this?
The technical problems can easily be solved by technical solutions, as explained.
Its harder with the human problems. We have to do some basic tasks, that we managed to avoid in the past years.
We should define some social project rules (or project constitution) for project members and contributors. Not just some netiquette, but also a definition, which project roles we have, which responsibilities they have and what will be decided.
Some things that I would suggest there, not really structured:
- A short Project Goal to start, with a link to a more detailled project vision.
- No personal attacks, no strong words, no secret agenda.
- The license decision should be repeated there.
- Who does not contribute, does not decide.
- This includes video tutorials and mods, which are not part of the project, but part of the SSU community.
- A project moderator should be available to moderate disputes and deescalate
- Problems should be mentioned when they appear, not when somebody else notices them as well.
- There should be a regular discussion thread about the features for the next milestone. It should get closed after the discussion is over and the decision for the mile stone be written into the wiki.
- No changes to the repository without a ticket that requires it.
- Commit messages should refer to the ticket
- A commit should be for a single ticket, not multiples
- C++ code should conform to the coding standards of SSU
- It should be possible to test SSU by just installing its package into Orbiter.
- We have an product owner, who is responsible for the tickets, the milestones and the quality of both.
- The product owner represents the whole team. He does not decide features or bugfixes himself, but makes sure that those decisions of the team will be implemented.