Minor change to CMake rules for PK3 archives

[Blzut3]

It's a bit curious, though, why such individual packages never updated.

Long term stable distributions are built around the idea that the user should never have to worry about an update breaking their code/software, so all tool chain versions are frozen at release with only security patches and bug fixes back ported. To relate this to the Windows world, imagine if Windows 10 didn't do feature upgrades (like older versions of Windows) and shipped with VS2015 out of the box. You would not expect that Microsoft would suddenly automatically upgrade VS when VS "15" comes out. Instead you would expect to have to opt in to the upgrade. Even if you do think the tool chain should update automatically, I'm sure one would be singing a different tune if the upgrade happened just before some major deadline.

This kind of falls apart for user desktop oriented software so distros like Ubuntu make exceptions for some programs like web browsers, but it's a blurry line on what should and should not get updated throughout the support life cycle. I personally think that Ubuntu is a little too conservative still, but I don't have a problem with subscribing to third party repositories for software I care about getting updates for like LibreOffice. In any case though, this is pretty much the basis for the endless debate over rolling release vs long term stable release distros. Everyone has a different idea on how software should get updated, and there's not really an objectively correct answer.

[Rachael]

That makes sense. Thank you for that explanation.

[Graf Zahl]

Everyone has a different idea on how software should get updated, and there's not really an objectively correct answer.

The correct answer would be to notify the user on a regular basis (say, once a week or month), list all updates and then let the user decide and either accept, decline or delay the update. Not doing anything and sticking with the old version is just asking for trouble, especially if this misses out on important features.

[Blzut3]

The correct answer would be to notify the user on a regular basis (say, once a week or month), list all updates and then let the user decide and either accept, decline or delay the update. Not doing anything and sticking with the old version is just asking for trouble, especially if this misses out on important features.

This is basically what Ubuntu does for the kernel and graphics stack. I don't expect them to expand beyond that as the maintenance burden would be too high since you're effectively promising security patches for multiple versions of software for some period of time. Besides, those who want to upgrade everything in regular increments just use a distro that releases more often (in Ubuntu's case, update every six months instead sticking to the LTS releases every two years). Also allowing people to outright decline upgrades means exponential growth in supported combinations.

The other option of forgetting about people to hold back is exactly the same as using a PPA.

[biospud]

Most importantly, which version of CMake did you use. I know that ZDoom stuck to 2.4. for far too long because that's what the Linux package managers were offering. It may just be that this requires later features.

2.8.12.2 is what comes up in my console window.

Thank you Eruanna for turning me on to Ubuntu-on-Windows. Sadly CMake 2.8.12.2 is the version that comes up in Ubuntu-on-Windows, because Ubuntu-on-Windows uses Ubuntu 14.04, which is 2 years old, and is a "long-term-support" version, which means it is especially conservative about package upgrades. I fervently wish for Ubuntu-on-Windows to grow and continue and get updated to more recent versions of Ubuntu. That would be so much better than continuing to lean on cygwin, as I have for years and years. And it would provide a pretty snappy answer to those smug Mac partisans who enjoy pointing out that Mac OS X is more linux-y than Windows is.

Anyway, those problem quotation marks are now out of the zdoom source, thanks in part to your diligent reporting. At your convenience, could you please verify that the latest zdoom code is working OK?

[Rachael]

CMake works now with UoW.

And that's fine - I simply went to VirtualBox and installed Ubuntu 16.04 anyway, which has a more recent cmake. That's how I got QZDoom to compile on Linux. I'm still trying to get it to work with UoW, though, it's a lot more difficult because you pretty much get a server core (if even that) and nothing more with UoW and a lot of things seem to have to be done by hand compared to a desktop Ubuntu install.

If you use UoW, I recommend you find a project called "MobaXTerm" - it supports OpenGL and once you set it up it allows you to run X applications. If you don't need OpenGL, Xming works just fine, and it's probably better. I'm still trying to figure out how to get sound working, though.

[biospud]

Folders aren't built correctly... they appear as a single entry in Visual Studio that doesn't do anything when you attempt to double click them (actors, graphics, shaders etc). Can anything be done about that, ie can folders actually be built into filters that work in the MSVS IDE?

Well it was a bit more work than I expected, but I just now submitted a pull request that creates subfolders in the MSVS IDE Solution Explorer like pk3->"Source Files"->"actors"->"chex"->chexammo.txt etc.

This "minor change" is now on its third iteration. I tested this latest version with CMake versions 2.8 and 3.5.
I also tested on Windows 10 and Linux Ubuntu 16.

Pull request at https://github.com/rheit/zdoom/pull/823

[Rachael]

You know what they say - if it don't broked it's not fix it. Apparently, that holds especially true for CMake files. But it'll be nice to have that extra convenience though.

[Nash]

Thank you biospud! And sorry for the inconvenience caused. :'(

[Edward-san]

Please remove all these 'merge branch master' from your commits. It's bad when trying to bisect the changes.

Also I think you should've made a new thread in 'code submissions' for the new PR.

Last question: why here you use \\ as the path separator instead of / like here?

[Graf Zahl]

New thread and cleaned up PR, please. Although I normally do some cleaning up myself on dirty PRs, they should be discouraged.

[biospud]

Please remove all these 'merge branch master' from your commits. It's bad when trying to bisect the changes.

Also I think you should've made a new thread in 'code submissions' for the new PR.

Last question: why here you use \\ as the path separator instead of / like here?

OK I'll clean this up and make a new thread later tonight. Thank you for the feedback. I'm still learning how to be a good citizen here.

The double-backslash \\ separator is needed for IDE folder categories within the cmake source_group command, and is quite specific to this particular usage. https://cmake.org/cmake/help/v3.0/comma ... group.html

The single slash / separator is used as the system-agnostic filesystem path separator within cmake, and can be used for a wide variety of filesystem path calculations.

[Rachael]

I'm still learning how to be a good citizen here.

Don't feel bad. My repo is a mess with me learning how to use Git. >_< I'm hoping that'll clear up, but that's going to suck horribly for anyone years from now looking to understand QZDoom's humble beginnings...