Advertisement

Visual C++ messing up again.

Started by August 17, 2000 09:52 AM
8 comments, last by Kylotan 24 years, 4 months ago
Wonderful. When I compile one of my project''s files, it fails to compile... it just sits there forever. Eventually I have to click the ''Stop Build'' button to abort it. If I then retry compiling it, I get this error: Compiling... Command line warning D4028 : minimal rebuild failure, reverting to normal build desc.cpp fatal error C1033: cannot open program database ''c:\coding\myproject\debug\vc50.pdb'' Basically, it''s failing to close the pdb file when I click abort or something. I need to reboot to close the file, which is a hassle, and even then, the code file is still not compiling. Anyone had a similar problem? I''m using VC5.0, introductory edition I think.
Sure, with VC++ 6. I end up exiting and restarting the compiler, running a clean and then trying again. More often than not it works.
Advertisement
Sadly, a ''clean'' for me means a 30 minute recompile. I just don''t have time to rebuild all that often. *sigh*
30 minutes? OMG!

Is your PC slow, or is your project massive?
I mean, it takes about 3-4 minutes for me to rebuild Quake 1!

Martee
Magnum Games


Edited by - Martee on August 17, 2000 7:27:05 PM
ReactOS - an Open-source operating system compatible with Windows NT apps and drivers
Hey Kylotan,
You may want to seperate files that you are more or less done with into seperate modules. If you make them staticly linked libraries, you can really cut down on your build time. If you need help doing this, let us know.

Later,
Eck

EckTech Games - Games and Unity Assets I'm working on
Still Flying - My GameDev journal
The Shilwulf Dynasty - Campaign notes for my Rogue Trader RPG

Quake 1 is in C. It doesn''t have a billion and one template classes to instantiate for each module.

My project has over 60 CPP files and probably just as many header files. I also extensively use the STL deque, list, map and vector classes, which seem to account for most of my compile times. There is little point making statically linked libraries, as no part of the project is ''finished'' and header file dependencies mean that I would be remaking most of them every couple of days anyway.
Advertisement
You could try expanding your precompiled header to include more classes? It might save you some compile time, but then a full rebuild will cause that to be rebuilt as well. Very painful problem... *sigh* probably due to microsofts unparallelled implementation of templates **sarcasm**


Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.
It's only funny 'till someone gets hurt.And then it's just hilarious.Unless it's you.
Kylotan, you''re not the only one!
I also got that problem sometimes!
If I do, I rewrite or re-order some of the last written code lines...then the compiler takes it...strange (bad) but true...

Since I upgraded to VC++ 6.0 most of my problems have gone away. Have you considered upgrading? (You can buy it at CompUSA for around $90)
I don''t use precompiled headers. There is little point, as I have had to seriously unpick my module dependencies so that I don''t end up recompiling everything each time, and that means that almost no set of included headers are anything like the same as those used by the next module. Of course, I could throw them all back in one header and use that as the precompiled header, but I change 1 or 2 header files daily and that would start to be a cause of long recompiles too.

Also, this is not a pure Win32 project. Therefore, I don''t want the grief of having to change all the #include statements around when I get to putting it on Linux, which doesn''t have a compiler supporting the same precompiled header mechanism, as far as I know.

As for buying VC6.0... well, I don''t have $90 spare I''d consider mugging an elderly passer-by for the cash if I thought it would halve my compile times though.

And I fixed the original problem by swapping the order of two #included files around... just enough to ensure it wasn''t going to spit out the same code, which was obviously hitting a bug in the compiler. (Before anyone suggests turning optimisations off... they weren''t on: as I only have the lowest edition anyway, which doesn''t do any significant optimisation.)

This topic is closed to new replies.

Advertisement