ZDoom

Nash wrote:... or am I doing it totally wrong. :S

I believe so, if your files are listed in the CMakeLists they should appear in the same folders on the left. If you added new folders then you just need to add a source_group rule for them (see the bottom of src/CMakeLists.txt). Also make sure your header files can be found in the "file( GLOB HEADER_FILES" rules in that same CMake file.

The unmodified generated project should be more or less identical to the hand made one outside of a few extra things that CMake adds to keep itself updated automatically.

Yes it's all good but I still keep the old VS2010 project file when I'm editing. I like using the IDE and seeing the source files all placed into folders on the left, and using Ctrl Shift F on the old project is much easier too. I would have a separate instance of Visual Studio open with the generated CMake stuff so I'd have to constantly switch windows while I work.

... or am I doing it totally wrong. :S

Didn't we solve all of your CMake issues?

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

I do, actually. I still find the old project files useful (well, for MY setup anyway).

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

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.

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

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.

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

Nash wrote: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. )

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)

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.

Graf Zahl wrote: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?

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

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