How do I compile Chocolate Doom under Windows?

[xbolt]

Hi, I'm thinking about building my own version of Chocolate Doom, and I can't find instructions on how to compile under Windows. Can anyone help me?

[exp(x)]

There is a codeblocks project file included in the subversion repository. I haven't tried using it myself, but I imagine it should work.

[xbolt]

I downloaded Codeblocks, and I open chocolate-doom.workspace, but when I try to compile, it gives this message:

ld.exe: cannot find -lpcsound

Any idea what's going on?

[Opulent]

does that resource exist? perhaps the header or the includes has the wrong path.
try a verbose compile

[fraggle]

Do you have a file named libpcsound.cbp? If not, where did you get the svn copy from? Did you do a direct svn checkout or did it come from somewhere else?

[xbolt]

Yes, I did a direct SVN checkout, and I have libpcsound.cbp.

[RTC_Marine]

So you did the following:

1) Open the workspace
2) 'Activate' the chocolate-doom project (should be bold text)
3) Menu: Build->Rebuild

And it still outputs that error? that weird because someone else was having this problem, yet all it required was adding a path to the linker settings in the chocolate-doom project (which is there already and on the repository)

[xbolt]

Yes, I did all three, and it still gives the error.

[b105xor]

Sorry, I am new to GCC, codeblocks, and I am trying to wrap my head around chocolateDoom. I followed the instructions on the Chocolate Doom page, but I am getting this same error. I do have libpcsound.cpb in my codeblocks directory. The only thing I have dug up was this trivia:

-------
2008-09-16 01:17:20 rtc_marine

- Force use of dwarf-2 debugging information - Fix an age-old problem of not being able to find -lpcsound, the debug target was looking for it rather than -lpcsound-dbg
-------

But not much actual insight. Any suggestions?

[b105xor]

HA - ok, I had opened just the game project, not realizing it was stitched to the other projects through main.workspace.

Your questions above were clues to help me figure this out - thnx!

[exp(x)]

I can't really help you there, but if all you want is the latest subversion revision, you can find my cross-compiled Windows binaries here. An alternative to Code::Blocks might be to use the standard './configure; make' method with cygwin. You may need to compile the SDL stuff by hand first, though.

[b105xor]

Actually, I am fooling around trying to figure out which current port would be the best starting point for a new port. Yes - another port! Well its for a new platform so that's what you got to do.

Your suggestion though sounds like a good idea, just for another view and way to get a little more insight.

[Quasar]

Anybody know if the Visual C++ 2008 project is currently functional? I need it in order to work on Choco Strife.

[Gez]

Last time I tried, it wasn't.

[fraggle]

Quasar said:

Anybody know if the Visual C++ 2008 project is currently functional? I need it in order to work on Choco Strife.

Don't count on it. If you really want to use MSVC, you'll probably have to update the project file yourself to get it working.

I think there was a working MSVC project file on raven-branch (which strife-branch is derived from) at one point but I don't remember.

[Quasar]

fraggle said:

Don't count on it. If you really want to use MSVC, you'll probably have to update the project file yourself to get it working.

I think there was a working MSVC project file on raven-branch (which strife-branch is derived from) at one point but I don't remember.

Guess I'll bite the bullet at some point soon then ;) We have mobjinfo/states/sprites tables which are ready to go in as a first step.

[Dragonsbrethren]

Speaking of compiling, the raven-branch Codeblocks project won't compile for any of the games or the setup program:

-------------- Build: Release in libtextscreen ---------------

Target is up to date.

-------------- Build: Release in libpcsound ---------------

Target is up to date.

-------------- Build: Release in Doom ---------------

WARNING: Can't read file's timestamp: C:\Users\Dragonsbrethren\Coding\Doom\Chocolate Doom Raven Branch\src\doom\deh_io.c
WARNING: Can't read file's timestamp: C:\Users\Dragonsbrethren\Coding\Doom\Chocolate Doom Raven Branch\src\doom\deh_main.c
WARNING: Can't read file's timestamp: C:\Users\Dragonsbrethren\Coding\Doom\Chocolate Doom Raven Branch\src\doom\deh_mapping.c
WARNING: Can't read file's timestamp: C:\Users\Dragonsbrethren\Coding\Doom\Chocolate Doom Raven Branch\src\doom\deh_text.c
Linking executable: ..\bin\chocolate-doom.exe
mingw32-g++.exe: ..\obj\chocolate-doom\rel\src\doom\deh_io.o: No such file or directory
mingw32-g++.exe: ..\obj\chocolate-doom\rel\src\doom\deh_main.o: No such file or directory
mingw32-g++.exe: ..\obj\chocolate-doom\rel\src\doom\deh_mapping.o: No such file or directory
mingw32-g++.exe: ..\obj\chocolate-doom\rel\src\doom\deh_text.o: No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
0 errors, 0 warnings
 

-------------- Build: Release in libtextscreen ---------------

Target is up to date.

-------------- Build: Release in libpcsound ---------------

Target is up to date.

-------------- Build: Release in Heretic ---------------

Linking executable: ..\bin\chocolate-heretic.exe
..\obj\chocolate-heretic\rel\src\heretic\d_main.o:d_main.c:(.text+0xdc1): undefined reference to `DEH_Init'
..\obj\chocolate-heretic\rel\src\heretic\d_main.o:d_main.c:(.text+0xdfc): undefined reference to `W_ParseCommandLine'
..\obj\chocolate-heretic\rel\src\i_sound.o:i_sound.c:(.data+0x1c): undefined reference to `music_opl_module'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
3 errors, 0 warnings

-------------- Build: Release in libtextscreen ---------------

Target is up to date.

-------------- Build: Release in libpcsound ---------------

Target is up to date.

-------------- Build: Release in Hexen ---------------

Linking executable: ..\bin\chocolate-hexen.exe
..\obj\chocolate-hexen\rel\src\hexen\h2_main.o:h2_main.c:(.text+0x9f6): undefined reference to `W_ParseCommandLine'
..\obj\chocolate-hexen\rel\src\i_sound.o:i_sound.c:(.data+0x1c): undefined reference to `music_opl_module'
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 0 seconds)
2 errors, 0 warnings
 

-------------- Build: Release in libtextscreen ---------------

Target is up to date.

-------------- Build: Release in Setup ---------------

Compiling: setup-res.rc
windres.exe: can't open file `setup-manifest.xml': No such file or directory
Process terminated with status 1 (0 minutes, 0 seconds)
1 errors, 0 warnings
 

[Quasar]

I might be excused for thinking the Chocolate Doom branch situation has gotten a wee bit overly complicated ;)

[fraggle]

It's nothing to do with branches, the problem is having multiple build systems.

The canonical build system is using autotools and make. That's what I use and I don't use anything else. There are Codeblocks and MSVC project files in there but I have never used them so YMMV. To his credit, Russell does a great job of keeping the Codeblocks project files up to date. It looks like they haven't been updated on raven-branch to match some changes I made a few weeks ago, hence the build problem above.

The MSVC files are another matter entirely; on several occasions I've seriously considered simply removing them entirely. Updates for them appear have appeared often enough so far that I haven't done that yet. Hopefully if you're going to start using MSVC that situation should improve :)

In the end I'm still rather uncomfortable about having multiple build systems, even if they are well-maintained. There have been bugs found and reported in the past, for example, that were caused because of inconsistencies between the Makefile and Codeblocks build systems.

[Gez]

It might be worth it to look into CMake, then? Its role is to generate project files for the various IDEs and make tools out there, so that there's only one set of files to maintain and the cross-platform variants are generated automatically...

[fraggle]

I already have a build system that works on every platform.

[Gez]

But it doesn't generate project files for CodeBlock and MSVC...

[Quasar]

Gez said:

But it doesn't generate project files for CodeBlock and MSVC...

There are ways to use the Microsoft compiler with GNU tool chains. The compiler and linker are command line runnable tools just like with pretty much every other compiler ever written.

However doing this completely precludes the ability to compile within the IDE, which is what I prefer to do.

For me it's not that I think MS's compiler is so great, but that I really dislike hand-modifying build scripts. I'm bad at it, and I usually just end up screwing them up.

[chungy]

Should be possible to use the Microsoft compiler and linker with the autotools scripts anyway by passing options to ./configure or setting environment variables. Still would require Cygwin or MSYS installed (of the two, Cygwin would be better since MSYS was forked off from Cygwin 1.3 and never really updated :p)

[MP2E]

chungy said:

.... Cygwin would be better since MSYS was forked off from Cygwin 1.3 and never really updated :p)

Not true, MinGW is now using GCC 4.5.0 and is very much updated. The main issue with MinGW is that the INSTALLER never gets updated, you always have to update the executables yourself. However, I think it's worth it, Cygwin uses a POSIX emulation layer that can really slow things down, whereas MinGW is a native Windows compiler that just happens to be GCC :P

[chungy]

MSYS, not MinGW itself :p MSYS is just a minimal Cygwin 1.3.x environment for running stuff like configure scripts and GNU make. Honestly, it shouldn't really matter which you use if using Microsoft C anyway.

[Graf Zahl]

fraggle said:

I already have a build system that works on every platform.

If you refer to autotools, well, I do not consider this a system that runs on Windows. I'd have to install some crap first that I neither need nor want to install.

And I think I'm not alone when I say that I never ever bothered to get some autotools-based project get compiled. Too much of a hassle to get everything set up.


Regardless, what's so hard about fixing the MSVC project? The only things that seem to be a problem to me is referencing the SDL headers and a handful of warnings concerning integer type truncation.

[chungy]

You have to install MSVC first too before using its project files. (And for what it's worth, autotools does run on Windows. Installing a DLL (cygwin1.dll) doesn't mean it's not running on Windows for some reason.)

Anyhow, fraggle just doesn't use it, he can't maintain the project files himself. I believe he's made it clear that he'll check-in updated copies if someone, such as Quasar or Graf or whomever, simply updates them and sends the corrected ones.

[Graf Zahl]

chungy said:

You have to install MSVC first too before using its project files.

That argument doesn't really count because every semi-serious Windows developer will have it installed already as it's the de-facto standard development platform for Windows.

On the other hand, very few people in the Windows world will want to use some obtuse Unix tools.

There's a reason why a good cross-platform tool like CMake was invented.

[exp(x)]

Graf Zahl said:

Regardless, what's so hard about fixing the MSVC project? The only things that seem to be a problem to me is referencing the SDL headers and a handful of warnings concerning integer type truncation.

Who said anything about it being hard? I'm pretty sure the issue is that Fraggle doesn't use MSVC.