Nash's SVN builds - DISCONTINUED.

[Quasar]

You need SDL_net also, and ALL of the DLLs that come with SDL_mixer. You also need the base hierarchy, which is why it is part of the SVN repo. EE will not execute without a visible base folder - either in the current working directory, the executable file's directory, a directory specified via -base on the command line, or a directory specified by the ETERNITYBASE environment variable. This is a Quake-engine sort of thing that we have gone with in order to keep EE's external data files organized. (It is also even possible to create your own games or to store your standard IWADs under this directory and use -game to pick what game you want to play )

So let's recap:
SDL 1.2.12 or later
SDL_mixer latest version and all DLLs it ships with (mainly for ogg and mp3 support)
SDL_net latest version
snes_spc DLL from the snes_spc subproject, if HAVE_SPCLIB was defined when you compiled anyway
base hierarchy

If EE doesn't run with all of these things visible to it, then please post any and all error messages you are receiving. Something else is clearly wrong if that is the case.

Also please be aware that to create a distributable EXE you'll need to be sure to compile the Release (vs debug) build. Debug depends on the MSVCRTD.dll file and in my experience, this file is not present on systems that do not have MSVC++ installed.

[Daniel]

Oh, please. That's an obvius question! Nash, you're THE MAN!!! Don't even think about stopping your custom builds! This keeps ZDoom alive for sure!!

[Nash]

Thanks for your support (and everyone who voted) - I guess I'll just continue doing what I have been doing.

My build environment is pretty much setup... except for one problem with SVN revision numbers. Back then, I used some ancient command line svn tools, and added an environment path to Windows XP and it worked fine.

Now I'm using the new SubVersion tools (the one that's linked from the ZDoom wiki) but I can't seem to get it to work. My builds keep being labelled as r0.

I've already set the correct directories in VC++ Options menu. Could it be because it has a problem because of the directory structure I use (D:\Projects\Subversion\bin\ -- back then it was just C:\SVN\ :P)... ?

[Enjay]

Don't see why your path would be a problem. Mine is in f:\program files\subversion_1.5.0 For some reason, I couldn't get environment patch working for anything I set up in VC++ so I just used explicit paths instead.

I have explicitly told Visual C++ to look there by setting up that path in "Tools/options/Projects and Solutions/VC++ Directories/Executable files" I don't know if it will named exactly the same in your version, but that works for me.

[Nash]

Yes, as I've already said, the path is setup correctly in the options menu - under executables - yet it's still not working.

I'll try to dig up the forum to see where Randy linked the command line versions of the tools... I prefer them anyway.

EDIT: Hmm, it wasn't Randy who linked the tools. I wonder who...

[Rachael]

Eternity is now hosted... with a couple strings attached. You can't run it on XP/IE7 machines. I believe it is because of the scripting language they're using, but honestly, there isn't much I know about it.

http://forum.drdteam.org/viewtopic.php?p=31345

[Quasar]

That shouldn't be getting dragged in. Is there any way you can find out what exports it is using from this DLL? If you can, I would love to remove them.

This is one reason why we have not upgraded from 6.0 yet. Compiling applications with later versions that will still run under Win9x and WinXP becomes increasingly more difficult as you move up, and I'm not ready to restrict my user base that much.

It could be the common problem with the SDL_main library. If so, the only way to fix that is to modify Eternity to contain the source code to the SDL_main library instead of linking against it. If I need to do that, I may as well take care of it sooner than later. Thanks for your efforts to this end, it should wind up helping us out, as well as making your life easier.

[Rachael]

shlwapi.lib

1>i_fnames.obj : error LNK2019: unresolved external symbol __imp__PathRemoveFileSpecA@4 referenced in function _WIN_GetExeDir
1>.\Release/Eternity.exe : fatal error LNK1120: 1 unresolved externals

This is all the information that I can come up with, unless you have any other ideas how to find them. I removed the listed .lib from the list in order to generate this error.

[Nash]

This service has been discontinued. Please see first post.

It was fun, but I don't really see the need for me to do this anymore.

Requesting a mod to unsticky this thread.

http://forum.zdoom.org/viewtopic.php?f= ... 8&p=335517

[Demolisher]

*Sniff*

[Enjay]

But... I thought I just read that you had got it all working.

[Nash]

Yes, I did (the SVN numbering was due to an outdated Subversion - all I had to do was upgrade to 1.5.2). But beyond all that, I don't really see any benefits of me going through the hassle to try and keep the latest versions uploaded.

Sometimes it almost feels like I'm trying to compete. Do you get where I'm coming from? "Okay, so they have the latest versions, gotta upload faster, gotta upload faster"... users will eventually figure out, "the DRDTeam server always has the latest builds first, no point in checking Nash's for updates".

And all of this is really not what I intended. All I wanted to do was to serve the community when RazTK stopped, and I did it at my own leisure. Having to constantly keep up with the latest uploads (all done manually, no automation) is really not how I wanted this to turn out.

Switching back to the automated system doesn't make things better - if anything, it'll just be wasted electricity costs for me.

I really see myself doing all of the above for nothing when there is another source that does it better, faster and more efficient.

[Enjay]

One of the things I said when we started doing this was that I hoped no-one would start feeling like it was a competition so I'm sorry that you feel that way. I know that I and plenty of other people have appreciated your efforts.

I don't know how SoulPriestess is doing her updating but, rest assured, my uploads are definitely done manually. The only automated bit is that I have a batch file to create the zip and the gz. Possibly the reason that we have been quick in getting versions online is that there are two of us keeping an eye on the SVN. I'm not sure where SoulPriestess is based but I'm guessing it's a different timezone to me. Quite a few times I've built a version and uploaded it before going to bed and then when I check the server in the morning I find that there has been a newer one put online whilst I was asleep. I've noticed that Graf often updates quite late at night - often between 11pm and 1am for me (which must be a similar time for him) so I often catch his revisions and build them before heading off to bed and Randy is definitely in a different timezone to me (probably around 5 hours behind me) so I think SoulPriestess usually catches Randy's commits.

RazTK

Speaking of RazTK, does anyone know what actually happened to him? He was very active and he was updating the SourceForge pages, often a number of times a day, and then... nothing.

[Rachael]

*sigh* I am not happy to see you've made this decision, but I think I can understand why. I am sorry you feel this way, Nash.

Everyone has unanimously stated they want to see you continue uploading your builds.

My timezone is kinda unique, because even though I live in the U.S., I work at night, so I'm still on the opposite side of the world.

Other than that, I really don't know what to tell you.

[Quasar]

shlwapi.lib

1>i_fnames.obj : error LNK2019: unresolved external symbol __imp__PathRemoveFileSpecA@4 referenced in function _WIN_GetExeDir
1>.\Release/Eternity.exe : fatal error LNK1120: 1 unresolved externals

This is all the information that I can come up with, unless you have any other ideas how to find them. I removed the listed .lib from the list in order to generate this error.

I have committed a new revision which uses LoadLibrary and GetProcAddress to access the PathRemoveFIleSpecA function, after reading that this *might* resolve the issue on a Novell webpage. If you could try recompiling it now (do a completely fresh build to avoid any linker issues), and let me know if this has an effect, I'd appreciate it.

This is due to what could be considered a fatal design flaw in IE7 which causes shlwapi to have a dependency on the Vista-only delayed loading manager. People have been complaining about this on MSDN vehemently and MS in typical fashion refuses to respond.