SYSINCL.DAT
4 messages in this thread
I'm wondering about the accuracy of the documentation for VC 32-bit
edition regarding the "SYSINCL.DAT" file. You see a description of it in the
online docs under the topic "More information on Include Dependencies" for the
Workbench. It claims that this file is rebuilt if it is not found on startup.
This text file should contain the filenames of all include files that are not
expected to change and should therefore be removed from any automatically
generated dependencies.
Although I see a SYSINCL.DAT for my VC 16-bit edition, in the BIN directory,
there was none for VC 32. I experimented with renaming the MSVC\BIN file to
see if the VC 32 somehow found it, and would therefore re-create it, but it
didn't. I tried placing a copy of it in the MSVCNT\BIN directory, but when I
added entries to it, they had no effect and those files kept arriving in my
makefiles.
I started poking around with this because of the "feature" that the automatic
dependency generator adds all #include lines, even if they are #define'd out.
OK, it's a lot to ask for a full preprocessor to scan the dependencies, but at
least I wish the SYSINCL.DAT mechanism would work.
The docs are not clear about where the SYSINCL.DAT file should be located.
It's also not clear whether the exclusion of a file like "exec/exec.h" should
be included as EXEC.H or EXEC/EXEC.H.
Read action !
>Although I see a SYSINCL.DAT for my VC 16-bit edition, in the BIN directory,
>there was none for VC 32.
VC++ for Windows 3.1 (16 bit) uses sysincl.dat in the \msvc\bin
directory. VC++ for NT (32 bit) uses msvcincl.dat in the \winnt
directory.
>It's also not clear whether the exclusion of a file like "exec/exec.h"
>should be included as EXEC.H or EXEC/EXEC.H.
exec.h
1: SouGreat news, do so it's just a documentation bug.let.
2: What's the proper procedure for reporting bugs?
3: I've also found a problem with the parsing of the
4: string after #includefilename for #include, where the cimompiler acts differently
5: depending on whether the it's using pre-compiled headers or not.
6: /post
Great news, so it's just a documentation buglet. What's the proper procedure
for reporting bugs? I've also found a problem with the parsing of the filename
for #include, where the compiler acts differently depending on whether it's
using pre-compiled headers or not.
There is 1 Reply.
Read action !
John,
>Great news, so it's just a documentation buglet. What's the proper procedure
>for reporting bugs?
I'm pretty sure that one has been reported. In general, just post a message to
sysop and MS will pick it up.
Michael Meadows
Read action !