Issue in VC2010 compilation of TDM2.0 source

[sm2513]

Hello!

 

First of all, you guys are awesome

for bringing out a standalone TDM!!

 

One "issue" that i observed during compilation of

TDM2.0 source in VC2010 Ultimate on Windows 7 is that

the DirectX SDK path is hardcoded as

C:\Program Files (x86)\...

which caused the the 'Engine' project build to fail, as my path was different.

 

I had to go to 'engine.vcxproj', and manually replace all such paths

for the source to compile.

 

May i suggest that the path be taken from the environment variables

(DXDSK_DIR or DIRECTX_SDK_HOME) instead?

[Serpentine]

I ran into the issue a million times - but some of the team prefer the static paths for whatever reason.

 

The move to cmake should make a lot of this go away, but... that's still work at the moment.

[greebo]

Let's suppose we actually switch to cmake, would I still be able to use Visual Studio for compiling and debugging? (Without maintaining a separate tree of .vcproj files, of course)

[Serpentine]

It generates the VS files for you, you keep your personal copies and do whatever you want locally.

 

Edit: I should say, when large changes are made involving the cmake files changing, the VS projects check with cmake before you compile and it will make the adjustments then, so that nothing is out of sync.

 

The VS files it generates are pretty damn good. If you have a few minutes free, try it out on dhewm3, which is what I want to base it on. Really, it's a breeze compared to maintaining the 3 systems we currently are.

[greebo]

I read about that (cmake generating the .vcproj files for you). It's a minor step back in the workflow I'm used to, since I have to remember to do all structual changes in the cmake list, any direct changes to my local .vcproj files would get lost. I've had worse workflows in the past, mind you, so it's probably acceptable if people are ok with that change.

 

It's not my call of course, since I'm not working on anything TDM-wise anymore, but whatever you do, keep in mind that the majority of coding workload in TDM is done in Windows and in Visual Studio, so it's a good idea to make it as easy as possible for those folks. At least it'd be nice to sync up with the other coders before switching the build system.

[Serpentine]

It's not my call of course, since I'm not working on anything TDM-wise anymore, but whatever you do, keep in mind that the majority of coding workload in TDM is done in Windows and in Visual Studio, so it's a good idea to make it as easy as possible for those folks. At least it'd be nice to sync up with the other coders before switching the build system.

 

I will do greebo

 

I just got so frustrated by not wanting to get in your way earlier this year, I know I'm not the greatest actual developer, but I want to be able to get people into the project easily. Not so we have a bag of fools, but so we dont chase away people short on time. Had some excellent offers in irc over the past two days, one of whom seems very capable with opengl etc. So hoping to just ease people in a bit more.

 

But I will try my best to make the breakage as short as possible, and take precaution to have the Windows libs ready, the conversion process documented for the rest.

 

Needless to say, I need to do the port again first

[sm2513]

Switching to cmake would involve learning its syntax,

and result in more code to maintain.

 

Maybe if the environment variables were setup

as a "best practice" on the systems,

that would save the trouble of

cmake code generating the changes for you.

 

I know that there are internal Team dynamics and quirks,

so again, totally upto you guys!

Edited October 11, 2013 by sm2513

[Springheel]

I just got so frustrated by not wanting to get in your way earlier this year, I know I'm not the greatest actual developer, but I want to be able to get people into the project easily

 

You also need to run it by grayman, who has been doing at least 80% of the coding work for this last update. Getting coders who are short on time is fine, but not at the expense of making life more difficult for the ones who have been doing the heavy lifting.

 

I know nothing about coding, but any talk about a big, restructuring project at this point makes me quite concerned.

[Serpentine]

Switching to cmake would involve learning its syntax,

and result in more code to maintain.

We currently have 3 build systems, 2 of which use solutions which are not really portable, and the other is SCons which is a bit mad and wants to bite you.

 

Trust me on this, it's worth it at the end of the day.

[grayman]

But I will try my best to make the breakage as short as possible, and take precaution to have the Windows libs ready, the conversion process documented for the rest.

 

Speaking for myself ...

 

1 - No breakage in the trunk

2 - All restructuring must be done in a branch, and the branch must become stable before allowing the changes into the trunk

3 - These new coders you cite should try working in the branch, to make sure that what you've done allows them to begin contributing

4 - MSVS remains a viable tool for coding work

5 - You finish the job. And 'finish' means the work is in the trunk and the ship is still afloat

[Serpentine]

Yup, that's the plan.

 

Grayman - if I could ask you a favor - please can you try out dhewm3; For me, the instructions and build on windows work flawlessly, it's really easy to get going. On my nix boxes, its even easier.

 

Knowing that what I want to base the change on, is something you can work with -- before we go there -- is important. The only thing I would add to the above's instructions is that 'cmake-gui' which comes with CMake on Windows, is really handy if you're not sure what's going on with depends.

[grayman]

Grayman - if I could ask you a favor - please can you try out dhewm3; For me, the instructions and build on windows work flawlessly, it's really easy to get going. On my nix boxes, its even easier.

 

I've downloaded the source tree.

 

I've downloaded and installed Cmake 2.8.

 

When trying to build the source using Cmake's gui interface, it immediately gives me several errors, telling me first off it can't find MSVS version 6. ??

 

If you can create a set of instructions for me on how to correctly install, configure, and build, I'll be happy to experiment. I don't have the time to work my way through Cmake's error list one by one.

[jeaye]

As a C++ developer (admittedly Linux-oriented) looking at TDM as a potential project, I'll say that scons is a red flag that the compilation process is not going to be friendly (and it's not -- I can't even get past the pch). I'd argue cmake is not only more familiar (to modern Unixy people), but also more ubiquitous (on Unix-based machines).

 

If most of the devs on TDM are Windows users, the underlying build system should matter very little to them, since they're just using MSVC, etc. Who it really matters to are the people that don't have that luxury, or choose to do things differently (i.e. users at a shell). In which case, familiarity is the luxury. A counter argument would be that the existing devs are more familiar with scons and therefore scons should remain. That would be a valid argument, assuming said devs are not looking to open TDM to a broader variety of developers (but I believe they are -- or at least should be).

[gnartsch]

I am trying to compile the 2.0 source using Visual Studio 2010 Express and figured out that some headers are missing,

so I downloaded the Windows Driver Development Kit.

But I am still lacking some libs like nafxcwd.lib and potentially others.

 

1>------ Build started: Project: TypeInfo, Configuration: Debug Win32 ------

1>LINK : fatal error LNK1181: cannot open input file 'nafxcwd.lib'

2>------ Build started: Project: Game, Configuration: Debug Win32 ------

2>LINK : fatal error LNK1181: cannot open input file 'nafxcwd.lib'

========== Build: 0 succeeded, 2 failed, 1 up-to-date, 0 skipped ==========

 

So.... what exactly (and which version) is required to compile the code?

The Wiki article didn't help. Obviously the Ultima version of the Studio must contain some more stuff, which is not included in Express.

Tried installing the Win7 Platform Development Kit, but those libs are nowhere to be found on my disk drive.

Edited October 17, 2013 by gnartsch

[grayman]

I am trying to compile the 2.0 source using Visual Studio 2010 Express ...

 

You can only compile the DLL ("game") with Express. ("Release w/o MFC", "Debug w/o MFC")

 

To compile the engine ("engine") you need full MSVS.

 

MS decided not to include MFC in the Express version.

[gnartsch]

Ah, ok. That works. Thanks!

I am only interested in the DLL anyway.

Unfortunately Express does not support RemoteDebugging.