Welcome to ZDF!

Please... no OS wars. I already caught the message, things should go in /opt if they don't follow the FHS. I just blame Grubber, he's the one who made the AUR packages for the ports in the first place.

I have no idea what's happening there, but the DLL itself cannot be at fault as it is never linked against during compilation. This sounds like the import library gets an improper reference to the CRT being used. But I have no idea how that can even happen. I have linked against external DLLs often enough, from all sorts of compilers, and it never complained about such a thing. For a static library, yes, that's normal, but not for a DLL.

As for the differences, the point simply is that the debug CRT contains - big surprise! - debug enhanced versions of the functions that can output more error information (and have some asserts) and of course are compiled debug friendly (i.e. no optimization.) You can just as easily link a debug build against the release library but of course that'd make debugging a bit less convenient.

Graf Zahl wrote:Not sure what you are trying to say here...

It and the previous point are one and the same. Compile a DLL with /MT and then link to a project with /MTd. From what I recall you'll get duplicate symbol errors since the VCRT doesn't match. This isn't an intrinsic problem with the platform since MinGW can produce DLLs which VC++ can link regardless of the VCRT in use. In other words, it seems if I want to distribute a library in binary form, I need to build with MinGW or the end user needs to use the same version of Visual Studio with the same VCRT flag.

Linux and OS X don't have this problem to anywhere near the same extent. I imagine binaries from different standard c/c++ libraries are incompatible, but this changes far less frequently. Most importantly there's no distinction between the debug and release runtime so I don't need to deal with linking different libraries based on build type like VS wants me to do. (Obviously if all of your dependencies are in a single solution this issue is avoided.)

Blzut3 wrote:Forgot to mention VC++ has this weird inter version incompatibility thing going on, even between debug and release builds, static and dynamic VCRT.

Things like this happen since Debug is unoptimized code, often leading to different stack contents. But the way release code is reordered it's very hard to debug. I've never seen the code behaving differently, if there were discrepancies they were always caused by uninitialized memory and having different contents in it due to the code not being 100% the same.

This can be worked around by having MinGW around which can compile a DLL which links to /MT, /MTd, /MD, and /MDd. Want a static library though, seems to be though luck, but I'm looking into this some more.

Not sure what you are trying to say here...

Blzut3 wrote: As for debugging. Honestly can't say I've done anything with VS's debugger that makes it seem all that great. For the longest time (not sure if it's still true)

I've worked with all Msft compilers since Visual C++ 6.0. The debugger has mostly stayed the same. I've also worked with XCode's debugger and Eclipse, and both are quite shitty when directly compared.

Linux had the best memory debugger though (valgrind) which has found me lot of "release build only" bugs with little effort.

That it has. One has to wonder why such a thing hasn't been done for Windows yet...

Forgot to mention VC++ has this weird inter version incompatibility thing going on, even between debug and release builds, static and dynamic VCRT. This can be worked around by having MinGW around which can compile a DLL which links to /MT, /MTd, /MD, and /MDd. Want a static library though, seems to be though luck, but I'm looking into this some more.

As for debugging. Honestly can't say I've done anything with VS's debugger that makes it seem all that great. For the longest time (not sure if it's still true) Linux had the best memory debugger though (valgrind) which has found me lot of "release build only" bugs with little effort.

Blzut3 wrote:Otherwise you need to tell VS where your libraries are manually. (I've never personally had success with the latter. Probably forgetting to do something simple, but CMake makes this a lot less painful either way.)

It's not really that hard, there's a dialog where you can enter such paths - either globally for everything or separately for each project.
You are right, though, that this is proably the one sore spot in Visual Studio which definitely could use some improvement.

On the other hand, the debugger is magnitudes better than everything I have seen so far on other platforms, and that's where I spend far more time than on configuring a project.

You forgot install other library development kits, but wait they're not in the path, so VS can't find them. Now you can use CMake and input the stuff in manually since Windows users like fine grained control on where things are located, and thus the stuff can't be found automatically like Linux/OS X. Otherwise you need to tell VS where your libraries are manually. (I've never personally had success with the latter. Probably forgetting to do something simple, but CMake makes this a lot less painful either way.)

Compare that to 99% of the time on Linux where you just have your package manager install the dev package and then it just works. Windows is certainly doable, but it's consistently harder to set up than Linux. I've yet to find anyone that develops for all three major platforms say otherwise. (Note: OS X is a lot like Windows in terms of amount of manual configuring, although it does auto configure a little more often. To be completely fair to OS X though, a lot of my trouble has to do with having to force the older toolkits to work in order to support older versions of OS X. Something that Apple REALLY doesn't want you to do.)

Blzut3 wrote:setting up a Linux development environment is super straight forward compared to Windows and (although to a lesser extent) OS X.

So where's the problem with setting up a development environment on Windows? Install Visual Studio. Done. Years ago this was a hassle because the free tools were so poor, including Visual Studio Express, but these days it's no longer an issue.

Well since I started using Linux in 2008, I haven't once personally run into a problem running multiple versions of the same program.

I haven't had an issue with all versions of ZDoom accessing the same config file (switch from ~/.zdoom to ~/.config/zdoom aside). I find it to be true for most applications that sharing the config file between versions does no harm, so 99% of the time we get the benefit of not having to reconfigure the program for every version installed. In the rare case that it does pose a problem you're probably the developer of said program and can work around it, or in ZDoom's case the ini path can be explicitly given.

All other data isn't supposed to be tampered with (IWADs), so we have those in a read only section of the file system. For shared libraries like FMOD, there are two solutions in play. First libraries are tagged with their ABI version (e.g. libwhatever.so.1.0.0, note that the version number there is of ABI not the version of the library). Secondly, it does support loading from the same directory as the binary or any directory that's baked into the binary.

As for having multiple versions installed in general. Running from the build directory works for most programs, and if it's a more complex program (development tools) the PATH can be changed and where they look for files is usually a configuration option. Also they generally allow the binary name to be changed to have the version number.

In the end it's a nice system since it's practically uniform, setting up a Linux development environment is super straight forward compared to Windows and (although to a lesser extent) OS X. About the only real advantage I can think of to the way Windows does things is that installing source ports is trivial since "where do I put the game data" is relatively obvious.

Out of curiosity, how do Linux users deal with multiple versions of an application as sometimes that's necessary due to incompatibilities.
I got more than 20 ZDoom versions on my system and if they all accessed the same user data all hell would break loose.

Graf Zahl wrote:But may I ask why the different paths for ZDoom and Zandronum?

Backwards compatibility. I packaged them wrong initially and then I saw Ubuntu's third party packaging standards recommending /opt/packagename. I switched ZDoom over, but switching Zandronum over is a bit of a hassle since it would break everyone's Doomseeker configuration and stuff like that.

Another recommended practice I've seen is to put a symlink in /usr/bin, so even though the binary and zdoom.pk3 are physically next to each other, additional information is potentially needed to find where ZDoom is installed. Just depends on the distro as to what is considered ideal although even "bad" packaging works.

VoidMage wrote:

Graf Zahl wrote:What I don't understand what zdoom.pk3 has to do there. It's part of the binary package, directly tied to the executable it comes with. So by all sane reasoning it should be in the same place.

So, basically, the argument is "they're doing it wrong, cause they're doing it in a different way than one I'm used to".

No. What I'm saying is that stuff that belongs together should normally be stored together, otherwise all kinds of strange problems can creep up if more than one version of an application accesses the same data file which is actually version dependent.

Edward-san wrote:Yeah, I believe these maintainers are doing it wrong. drdteam debian packages put the executable, the pk3 and the libraries in one place (/opt/zdoom for zdoom, /usr/games/zandronum for zandronum). Then, in /usr/bin it's put a simple bash script called, not casually, 'zdoom', which calls the right program in the right place.

That sounds how it should be.
But may I ask why the different paths for ZDoom and Zandronum?

Graf Zahl wrote:What I don't understand what zdoom.pk3 has to do there. It's part of the binary package, directly tied to the executable it comes with. So by all sane reasoning it should be in the same place.

So, basically, the argument is "they're doing it wrong, cause they're doing it in a different way than one I'm used to".

While FHS is somewhat a blowback from the far past, where Unix was tied to specific hardware (you can google the bikesheding about "/usr separation" for some details), it has some its upsides.

For example, on some less than trivial setups, /usr/share can be a separate partition mounted with 'noexec' (meaning "Do not permit direct execution of any binaries on the mounted filesystem.").

Also, shell is actually useful there, so dumping noise is $PATH is quite unwelcome.

Yeah, I believe these maintainers are doing it wrong. drdteam debian packages put the executable, the pk3 and the libraries in one place (/opt/zdoom for zdoom, /usr/games/zandronum for zandronum). Then, in /usr/bin it's put a simple bash script called, not casually, 'zdoom', which calls the right program in the right place.