Graf Zahl wrote:The last one is a problem which needs to be fixed in the repo.
The others are irrelevant. Some of the external code is not 100% standard compliant and throws warnings as a result.
Oh, OK, so other than the one that needs to be fixed in the repository, I'm basically getting an acceptable exe when compiling with VC 2010 Express? If that's the case, I can stop trying to resolve the delayimp.lib error with VC 2008 Express. Thank you.
[edit] Though it's still nagging at the back of my mind. I reverted my checkout of GZDoom to a version that can compile using the solution that comes with the checkout and it compiles just fine. If I then use this same checkout to make a CMake solution file, I get the linking errors. Grrrr!!!![/edit]
b91d5d5eb57b1af6f43a2e323c73317e6bff4f65
The one just before the change "Allow use of system GME library". Seeing as how it was a GME related error that stopped the more recent revision compiling with its own sln file, I thought it would make sense to drop back to one before a gme change. However, for most of today, my copy of the repo has been right up to date and showing the delayimp-related problem.
Given that I can't compare like for like, I can't say absolutely hand on heart that the regular sln file wouldn't show the delayimp-related problems with VC2008 but, from everything I'm seeing, it seems very much that the sln file from the repo does not have these problems (and certainly never has to date in previous revisions - I have been using VC2008 to compile GZDoom for a little while now) but the CMake generated one shows the problems in both the up to date revision and the older one.
I don't know what it's doing, but I have checked over and over, inside caches, roaming directories and anywhere else I could think that temporary files might be stored to see if there was a rogue delayimp.lib file hiding anywhere. I've searched my HD repeatedly using Windows search and the cmd prompt. I definitely only have 2 copies of delayimp.lib and they are both pretty new (coming with VC2008 and VC2010). However, whenever I use CMake to construct a sln file for VC2008, I get the delayimp related problem.
Like I said, it doesn't happen with VC2010 and it doesn't happen when using the repo sln file with VC2008 so I have to conclude that CMake is doing something (using an unusual/out-dated parameter or something?) that makes this fall over when using it to make a VC2008 compatible solution. Why it doesn't upset VC2010 I have no idea, but it does seem to be a problem with VC2008.
Regarding DelayImp, I thought I had a sucessful compile with 2008, but the problem is most like it not linking against DelayImp. In src/CMakeLists.txt remove the if/endif around the following:
# For some reason this isn't implied on 2005
if( MSVC80 )
set( ZDOOM_LIBS ${ZDOOM_LIBS} DelayImp )
endif( MSVC80 )
Let me know if that fixes the issue for 2008. It might be worth not bothering with the version check and just passing DelayImp to the linker regardless, but I'm not on Windows right now to check if that doesn't cause issues for 2013.
Graf Zahl wrote:What revision did you revert to? Don't forget that Blzut only recently fixed the CMake files to properly work with Visual Studio.
Well strictly speaking, you could go all the way back to March 8th and get a binary. The recent changes just make sure the proper options are set so it behaves more like the hand made project.
I did notice that and wonder about it when I was poking through the files. I didn't play around with it though. I guess I should have.
I just tried and moving the "set( ZDOOM_LIBS ${ZDOOM_LIBS} DelayImp )" outside the if/endif does indeed allow a CMake sln file to compile with VC2008. Success! I have a functioning gzdoom.exe (tested) built using VC2008 from a CMake generated sln file.
I can't test 2013 but, other than the error messages already reported, this change still allows a successful compile with VC2010 too.
Having now had a play around with CMake, I can certainly see the appeal. Now that I know the difficulties were just teething problems and not really of my making, I can see how easy it is to configure things.
Without any real effort, I can create two different setups: one to compile using VC2008 and one using VC2010. The ability to easily specify where on my HD this takes place is very nice and the fact that this all happens without propagating all sorts of unwanted files and folders throughout my main copy of the repository is great.
The flexibility of the system has obvious advantages for a codebase that is likely to be downloaded by a larg(ish) number of people and compiled on their own setup.
Seems like there's a huge learning curve with this. I'll wait for GZDoom to officially deprecate gzdoom.sln before updating my codebase and finally taking the plunge with CMake. :D
(I also have been busy with other non-game projects at the moment so I really just don't have the energy to absorb all of this ATM. By following this thread I *think* I kind of know what this entire CMake business is supposed to be but I can only know for real once I actually get my hands dirty with it)
Nash wrote:Seems like there's a huge learning curve with this. I'll wait for GZDoom to officially deprecate gzdoom.sln before updating my codebase and finally taking the plunge with CMake.
Not really. But you'll have to invest a bit of time to understand what CMake does. Once your project compiles you shouldn't have to use CMake anymore.
As for GZDoom deprecating the .sln file, it's already done. I've just not yet pushed the change. But whatever happens, these files won't get updated anymore.
This thread probably makes things seem like the learning curve is much bigger than it is. However, most of what you see in this thread is me trying to figure out a problem that resulted from a single line in a file (which will presumably get addressed) and not something inherently difficult in using CMake. Using CMake itself is actually very easy. To get it working with GZDoom only took a few button clicks and probably less than a couple of minutes.
Graf said earlier (here or elsewhere) that setting things up with CMake is probably easier than doing it with Visual C alone and I think he's probably right: You run Cmake, tell it where the source code it, tell it where you want your builds made and click a couple of buttons.
You still have to install Visual C++ (or another compiler) and the other required files but, after that, setting things up is easier. You click a button called "Configure", tell CMake which compiler you want to use (it knows about a few, including a number of versions of VC), CMake reads the source, copies relevant files to your nominated build directory and tracks down where you have installed the various required libraries etc. The only important thing it couldn't find on my system was where I have installed nasm so I had to enter that manually (easy to do).
Then to make a build, you click a button called "Generate" and CMake creates the required files in your nominated build directory. One of the files that get created is a sln file. For me, double clicking that opens the correct version of Visual C++ and I can then tell VC++ to build the project. It does so in the nominated build directory thereby keeping my original copy of the repo nice and clean.
@Nash: The other thing to say about trying CMake is that it is totally risk free. It's a relatively small download and because it moves anything that will be used for compiling into a new folder, it doesn't affect your other files. So, if for some reason it doesn't work out, you can just delete anything that was created by it and you're back to where you were with no damage done.
Question: Is it possible to somehow configure CMake so it knows where to find nasm when I create a new project?
It's not a huge problem to point CMake at the location of nasm.exe but it would be nice if it could find it by itself. It's the only thing that I have to manually configure when I create a new project in CMake. As far as I know, I put it in the default location (c:\project files (x86)\nasm).
[edit] BTW, I have now used CMake to make Visual C++ 2010 solution files for GZDoom, ZDoom and my own (slightly) modified GZDoom. I have compiled executables from all of the solutions and they have all worked. [/edit]
Enjay wrote:[edit] BTW, I have now used CMake to make Visual C++ 2010 solution files for GZDoom, ZDoom and my own (slightly) modified GZDoom. I have compiled executables from all of the solutions and they have all worked. [/edit]
[wiki=Compile_ZDoom_on_Windows]This[/wiki] could use updating now.
