2.8pre-245-gfe67ae5 Compile error

[Enjay]

Affects GZDoom too

Code: Select all

.\src\sound\music_gme.cpp(43) : fatal error C1083: Cannot open include file: 'gme/gme.h': No such file or directory

[Graf Zahl]

Let me guess: You are using the VC 2005 solution file. I somewhat expected this problem to happen because the change only seems to have been made in the CMake project.

[Enjay]

You are correct.

[Graf Zahl]

Well, let's see what Randy does about it. Since I do not use VC2005 anymore I won't be able to fix these project files.

[Enjay]

Have you moved completely across to CMake for GZDoom? The above error was with VC2005 express but I was using VC2008 express with GZDoom.

[Graf Zahl]

The error is that a recent change was only made in the CMake files. So it's not surprising it also happens with VC2008.

When I installed my new working machine I didn't even bother installing all the old compilers. I got a brand new VC2013 Enterprise edition so why step down into those ugly depths again...

CMake is just fine, except for the one bug I reported. For that I'd like Randy's feedback first. Far easier to configure that Visual Studio directly and it doesn't have any compiler restrictions.
You can consider the .sln file in GZDoom deprecated. I won't maintain it any longer, ignore all errors reported with it, and just keep it so that updating from ZDoom is easier. (OK, I think I'll delete gzdoom.sln right away...)

[Enjay]

Far easier to configure that Visual Studio directly and it doesn't have any compiler restrictions.

Is there a "step-by-step" anywhere for getting ZDoom/GZDoom up and running with CMake?

[Graf Zahl]

No, but it's not that complicated. You have to start the CMake GUI, select the compiler of your choice, add a path where to generate the project and press the configure button. Then you have to manually add the paths it couldn't find itself - for me it was only the paths to the old DirectX SDK - Repeat this process until all errors age gone, select the options you want and generate a project.
It's actually a lot more straightforward than setting all this stuff manually in Visual Studio itself.

Once the project is generated it will update itself when necessary so you won't have to launch CMake again unless you want to use different settings.

[Nash]

Does that mean I should trash VC2010 too? If the solution is going to be deprecated?

(Not complaining; I'm cool with changes, I mean if I am supposed to move to CMake, I'd rather see the .sln deleted from GitHub so I don't get confused)

[edward850]

Does that mean I should trash VC2010 too? If the solution is going to be deprecated?

Why? You use CMake to make the VC2010 project file. Unless you have another IDE on hand you prefer. (Just so you know, you make it sound like you think CMake is an IDE. It isn't. )

[Nash]

I spent some time updating my dusty codebase to the latest GZDoom and I am also getting this GME compile error on my traditional VC2010 project file. I haven't mucked around with generating stuff with CMake yet so I'm guessing I should ditch that and start using CMake... ?

[Graf Zahl]

No surprise. The change that was made here in the code requires a configuration change in the project. However, since I no longer use the project the change won't get made unless Randi decides to keep it around.

[Enjay]

Yes, I got the GME error with the old solution file too. However, CMake does indeed fix things. In fact, it was getting this error that spurred me on to setting up CMake (as you can probably figure out from the rest of this thread).

[Nash]

Any temporary solutions on how to manually fix these in the traditional VC project files? It'll be some time until I finally sort out things with CMake and I'd just like to do quick builds to test the executables and make sure things even run at all with the new codebase.

[randi]

Fixed, not that I expect any of you care anymore.