Problem with first-time build of TDM 2.11 dev in VS 2022

[Geep]

Greets. I just setup VS 2022 Community/VC++/MFC on a fresh box, and did a Checkout with TortoiseSVC from the public repository of build 16481-9881 (matching a fresh 9881 dev install of TDM environment, as required).

When I do the build, I get a link error: Can't find file libavcodec.lib

I'm not finding that file in the working repository, although I do see the libavcodec folder and avcodec.lib

If I select DarkModTools/Properties, I'm able to go to the Link/Input field and see where libavcodec.lib is listed, but I can't edit it to change it to avcodec.lib (says it's inherited)

I'm kinda rusty, haven't used VS since 2015, so this may be a trivial thing. Help?

[nbohr1more]

The latest SVN source is 9917

what SVN tree are you using?

[duzenko]

Can we have a screenshot and build logs?

[stgatilov]

On 5/1/2022 at 3:35 AM, Geep said:

Greets. I just setup VS 2022 Community/VC++/MFC on a fresh box, and did a Checkout with TortoiseSVC from the public repository of build 16481-9881 (matching a fresh 9881 dev install of TDM environment, as required).

When I do the build, I get a link error: Can't find file libavcodec.lib

The third-party libs were changed somewhere around that time.
Maybe I had some uncommitted changes when published that update?...

Try revision 9882, or revision 9888, or 9891.

[Geep]

Used the public svn, not the team svn. Some forum comment made me think that 9881 was more stable its successor. I don't really need the very latest, at least not right now. TDM 2.10 would've been fine too, but who knows, maybe some issues building under VS 2022?

I'll try a later 2.11 revision as stgatilov suggests... probably won't be today though.

[Geep]

Sorry, I got waylaid putting up a new wiki page about the proc file format:

https://wiki.thedarkmod.com/index.php?title=PROC_File_Format

which you expert blokes are invited to poke holes in, as time & interest allows.

I'll try to reload 2.11 source this weekend.

[Geep]

The build succeeds now with the latest. Yea!

However, evidently the directory structure is not quite right for debug to work. I followed what the compile guide said (I think), with these 2 directories:

...Games/tdm11dev/darkmod_src/trunk/TheDarkMod.sln (etc.) [using TortoiseSVN]

...Games/tdm11dev/darkmod/TheDarkModx64.exe (& all the .pk4s, etc) [using tdm_installer]

It appears that the build process puts the results in

...Games/tdm11dev/darkmod_src/darkmod/

I tried changing adding a "." to the project output location to move the directory up one, i.e., DarkModTools property sheet, for the debug x64 configuration: Configuration Properties; General;

  Output Directory [changed from] $(SolutionDir)..\darkmod\ [to] $(SolutionDir)...\darkmod\

But that seemed to generate build errors subsequently, so reverted. I can probably munge this up so it works, but thought I'd ask your suggestions first.

[stgatilov]

Ideally, you should have checked out "trunk" directory only, so that its contents get into "tdm11dev/darkmod_src" instead of "tdm11dev/darkmod_src/trunk".

Do you BTW have all the "branches" and "tags" directories near "trunk" ?
Maybe not, because they are still closed for public for some weird reason...

[Geep]

OK, I'll try to rearrange to that directory layout. I'll have to lookup how to do that without screwing up Tortoise.

I'm not on that machine at the moment, so I can't check your BTW. I don't remember about "branches", but I do remember a local "tags" directory... don't know if it was populated.

[Geep]

Directory structure is working now.

The path to the executable is a bit funky (via the source directory), when local debugging is run directly from VS. It becomes:

[my drive and user account]\Games\tdm11dev\darkmod_src\..\darkmod\TheDarkModx64.exe

That's set by the call in win_main.cpp to Sys_EXEPath, which gets the path from GetModuleFileName (resolves to GetModuleFileNameA). The string is passed up to Sys_DefaultBasePath (which strips the filename off), and back up to the game init code.

Don't know if GetModuleFileNameEx would be better for this, give a cleaner path. Or if this weird path breaks anything, other than unnecessarily stressing the MAX_PATH boundary.

Do you guys usually set one of the "fs_..." command-line args to deal with this?

 

[stgatilov]

On 5/11/2022 at 10:55 PM, Geep said:

Directory structure is working now.

The path to the executable is a bit funky (via the source directory), when local debugging is run directly from VS. It becomes:

[my drive and user account]\Games\tdm11dev\darkmod_src\..\darkmod\TheDarkModx64.exe

That's set by the call in win_main.cpp to Sys_EXEPath, which gets the path from GetModuleFileName (resolves to GetModuleFileNameA). The string is passed up to Sys_DefaultBasePath (which strips the filename off), and back up to the game init code.

Don't know if GetModuleFileNameEx would be better for this, give a cleaner path. Or if this weird path breaks anything, other than unnecessarily stressing the MAX_PATH boundary.

Do you guys usually set one of the "fs_..." command-line args to deal with this?

No, we simply use the recommended directory structure, and everything works out of the box.

I mean:

• C:\thedarkmod\darkmod_src\TheDarkMod.sln
• C:\thedarkmod\darkmod\TheDarkModx64.exe

One thing I'll say for sure: better not mess with paths without critical need
You can break too much stuff.

[Geep]

Yup, looks like ample breakage possibilities.