llaffer2 wrote:I've tried off and on many times to try to compile this in windows with zero success.
Is someone who knows how to do it able to make a HOW-TO type of doc that walks through what is needed to compile it?
Thanks
How about the README-CVS file?
TiTnAsS wrote:Last thing i heard on the subject was iceman made a lot of adjustments and compiled through dos....mabye you should just stick witht he betas.
... wtf? compiling through DOS will never be supported...
TiTnAsS wrote:Last thing i heard on the subject was iceman made a lot of adjustments and compiled through dos....mabye you should just stick witht he betas.
... wtf? compiling through DOS will never be supported...
He's thinking about when iceman used MingW or something like that to do it and had to hack command.com with his disassembler or something to extend the line length, more than likely.
llaffer: Have you tried downloading Dev-CPP and using that? I don't know when it was last used, but I've been under the impression K's been testing regularly against free software build systems (MingW and Dev-CPP I think, maybe Cygwin too, don't know for a fact, though). I could be wrong, but give it a shot.
Be the devil's own, Lucifer's my name.
- Iron Maiden
Isn't the README in the armagetronad_build_visualc folder enough? If not, complain with the author (whoops, that's partly me) or ask specific questions. What have you roughly done so far, what sources are you trying to use, and at what point did you hit the wall?
h:\work\arm\armagetronad\src\tron\gcycle.cpp(1374): fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'f:\vs70builds\3077\vc\Compiler\Utc\src\P2\x86\fppeeps.c', line 1368)
H:\work\Arm\armagetronad\src\tools\tRecorder.cpp(600): error C2668: 'fabs' : ambiguous call to overloaded function
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(238): error C2440: 'type cast' : cannot convert from 'int' to 'rScreenSize'
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(246): error C2065: 'max' : undeclared identifier
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(246): error C2228: left of '.width' must have class/struct/union type
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(247): error C2228: left of '.width' must have class/struct/union type
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(247): error C3861: 'max': identifier not found, even with argument-dependent lookup
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(248): error C2228: left of '.height' must have class/struct/union type
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(248): error C3861: 'max': identifier not found, even with argument-dependent lookup
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(249): error C2228: left of '.height' must have class/struct/union type
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(249): error C3861: 'max': identifier not found, even with argument-dependent lookup
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(260): error C2228: left of '.height' must have class/struct/union type
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(260): error C2228: left of '.width' must have class/struct/union type
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(260): error C3861: 'max': identifier not found, even with argument-dependent lookup
H:\work\Arm\armagetronad\src\tron\gMenus.cpp(260): error C3861: 'max': identifier not found, even with argument-dependent lookup
H:\work\Arm\armagetronad\src\ui\uInput.cpp(408): error C2668: 'fabs' : ambiguous call to overloaded function
H:\work\Arm\armagetronad\src\ui\uInput.cpp(408): error C2668: 'fabs' : ambiguous call to overloaded function
H:\work\Arm\armagetronad\src\ui\uInput.cpp(415): error C2668: 'fabs' : ambiguous call to overloaded function
H:\work\Arm\armagetronad\src\ui\uInput.cpp(415): error C2668: 'fabs' : ambiguous call to overloaded function
Windows client cannot be compiled right now with Visual C++ 2002 (VC7, the one you are using) or Visual C++ 2003 (VC7.1) because all those errors. I believe only windows server can be compiled with those compilers from cvs right now.
You have two choices to build windows client in windows:
- use Visual C++6 (-> armagetronad_build_visualc)
- use Code::Blocks (-> armagetronad_build_codeblocks)
I tried and I failed. After finally finding this thread, I followed the directives in
armagetronad_build_codeblocks/README
to the letter. Building armagetron.workspace/armagetron/Release, I only had to fix one minor bug [1] to compile, but then the linker complained about missing libs for the windows libraries - apparently the workspace does not contain build instructions for those.
edit: The workspace refers to the neccessary projects, but the project files are not in CVS. I've asked klaxnek to put them there.
Regards
meriton
[1] current CVS/armagetronad/src/tron/egame.cpp:1821 reads:
uWebInterface::Shutdown();
I assume this should be withhin an #ifdef DEDICATED ? (It is not).
Hmm, I'm basically following these instructions for the GCC build in Windows. The only difference is that I use makedist.bat from armagetronad_build_visualc. I did not have to import/convert any projects, I just open the .workspace in code::blocks and build.
Oh, that reminds me: if you build the whole workspace, you need to move the armagetronad project all the way down, the libraries need to be compiled first. I'll commit the change to SF.
I deleted the dist directory and used the other makedist. The problem persists:
Linking executable: ..\dist\armagetronad.exe
mingw32-g++.exe: ..\armagetronad_winlibs\SDL\VisualC\SDL\Release\SDL.lib: No such file or directory
mingw32-g++.exe: ..\armagetronad_winlibs\SDL_image\VisualC\Release\SDL_image.lib: No such file or directory
mingw32-g++.exe: ..\armagetronad_winlibs\SDL_mixer\VisualC\Release\SDL_mixer.lib: No such file or directory
.libs? Instead of those, my code::blocks would be looking for corresponding .a files in ../dist.
Ahh, now I understand. You're working from the CVS trunk, and I'm on branch b0_2_8. IIRC, there were some improvements made to the build, especially the building of SDL and companions via mingw, before, you had to use a build from VisualC. Right, Klax?
I'll merge back the branch to the trunk as soon as we know beta4 is a more suitable mergeback point than beta2 and beta3 were.