Re: Is #include inside stdafx.h a bad idea?
On Wed, 24 Jan 2007 15:21:47 -0700, "Chris Shearer Cooper"
<chrisnews@sc3.net> wrote:
"Nathan Mates" <nathan@visi.com> wrote in message
news:12rfkshejhbiucd@corp.supernews.com...
In article <12rfe7u21j8oub1@corp.supernews.com>,
Chris Shearer Cooper <chrisnews@sc3.net> wrote:
In our Visual Studio 2005 application, we have several of our
application's
H files that are #included into stdafx.h.
What is odd, is that when we change those application H files, VS2005
doesn't trigger a rebuild of the entire app (or of anything, for that
matter).
I've seen a lot of projects not compile every dependent cpp file
when Resource.h is changed. Is this the kind of header file you're
changing? Btw, you can rename your precompiled headers to something
that's a lot more meaningful - no need to keep up with MS-DOS 8.3
filenames or a bad keyboard splattering that became a (lousy)
standard.
Yeah ... and I was wondering where the setting was, that said "don't rebuild
just because resource.h changed" ...
That setting is expressed in the comment at the very top of the file:
//{{NO_DEPENDENCIES}}
but no, the header files I'm changing
are not resource.h, they contain real live C++ class definitions ...
Where are the files located, and what are their names? VC++ has gotten
smarter about excluding files from dependency checking. In VC6 and earlier,
there was a file (sysincl.dat, IIRC) that contained many hundreds of names
of system (C, C++, Windows) headers, and the compiler would exclude any
file with one of these names, wherever it was located. Nowadays, the
compiler excludes whole directories, which makes a lot more sense. You
should also make sure the relevant .obj files aren't dated far into the
future.
--
Doug Harrison
Visual C++ MVP