Space Shuttle Ultra Project co-developer
- Feb 4, 2008
- Reaction score
That's why I told you to create VS2019 specific files and check those in. Then nothing would be broken, either for VS2017 or VS2019.
I'm surprised that a seasoned developer such as yourself doesn't seem to recognize this, but there's no maintenance of them. You create them once and then forget about them. They're not source files, they don't change daily or how often you open them. The VS2017 *.vcxproj files had been untouched for years until you changed them. I've no problem you change them locally to work for you in VS2019 Community, but where you erred was checking those changed files in, breaking them for the rest of with out telling us that we needed to switch over to VS2019.I have better things to do with my time than maintaining a second build system.
Seems like you have a broken set up there. It's complaining about something not being declared properly both in SSU and the general Orbiter SDK. As we haven't even touched the OSDK files, something bigger than SSU is at fault here. The only advice I can really give you is to re-install Orbiter and SSU.
You are out too? I guess that's it for SSU then. I'll close this thread upon confirmation.That's it.
I am getting too old for this .
You are out too? I guess that's it for SSU then. I'll close this thread upon confirmation.
Guys, I don´t understand anything. What happened here? As I read, I understand that whatever the problem is, it is present for years. How can this be?
1)OK, I'll own this one completely for missing the note about VS2019 in the commit log.From my point of view:
- Who does not develop the C++ part of SSU should not tell those who do, which version of the compiler they must use.
- We had big problems in the past ten years with people needing to use some obsolete Visual Studio and requiring maintaining two build systems.
- Instead of learning from the past trouble we had with VC 2008 to VC 2015, some non-developers is insisting on keeping the old build files.
- We could now use CMake now, like Microsoft also does for their C++ projects and which Visual Studio even supports natively, to get out of the version dependency of the MS project files.
- And CMake has no problems with Orbiter projects, as I can tell after testing it in other projects.
- Still #1 should apply there.
- Since VCPkg has a very good CMake integration, we could also use this as package manager for installing the C++ dependencies of SSU.
- And in this special case, I am especially disappointed of DaveS messing around with the project without even caring about the development. He treats it as a one-man show, fine, he has a one-man show.
OK, so the reason why didn't go the route of using CMake was that no version supporting Windows/VS was available until 2016? 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.For 4) The answer is quite simple: It wasn't available for Windows and Visual Studio.
It was a Linux tool, a replacement for the classic autobuild tool. AFAIR, the first version supporting Visual Studio appeared around 2012. The native Visual Studio support appeared first around 2016, for the 3.10 version. VcPkg was first released in 2016.
So far, only few people here in the Orbiter world experimented with CMake, despite it already being industry standard for C++.
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.