[Linux, Somewhere after r1316] Cannot find zdoom.pk3

[Blzut3]

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.

[Graf Zahl]

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.

[Blzut3]

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.)

[Graf Zahl]

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.

[Blzut3]

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.

[Graf Zahl]

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...

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...

[Blzut3]

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.)

[Graf Zahl]

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.

[Marisa the Magician]

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.