After running a build, I noticed an "llvm" directory inside the "win32"
directory--sure enough, tucked away inside this directory are the copied
config.h and ADT files that Configure is supposed to be creating--which it
But now I'm not sure of what's going on--why are there two config.h files?
It seems that this is what's happening; from the command-line call for
Support, which is built right after Configure:
/Od /I "..\..\include" /I ".." /D "_CRT_SECURE_NO_DEPRECATE" /D
"_CRT_SECURE_NO_WARNINGS" /D "_SCL_SECURE_NO_WARNINGS" /D
"_CRT_NONSTDC_NO_WARNINGS" /D "WIN32"
/D "_DEBUG" /D "_LIB" /D "__STDC_LIMIT_MACROS" /D "_VC80_UPGRADE=0x0710" /D
"_MBCS" /GF /Gm /EHsc /RTC1 /MDd /Fo"Win32\Debug\\"
" /FR"Win32\Debug\\" /W3 /c /Zi /TP /wd4355 /wd4146 /wd4800
"..\..\lib\Support\Allocator.cpp" (bunch more .cpp files)
From within the Support directory, "..\..\include" will pick up "#include
<llvm/Config/config.h>", but so will ".." (..\llvm\config\config.h). This
seems highly suspect, to depend on the order of inclusion inside of VS.
I also don't quite get what you mean by the following:
The file in the win32 directory is the config.h file that's ultimately
used when compiling everything under VStudio. That it implies that it
concatenates is outdated information. Ditto for the other .in files in
So they *should* be concatenated, or not? What's the outdated information
here? It seems offhand that they should be, but your prose above implies
that they shouldn't be.
Ultimately, it seems that the build script should be copying this config.h
(and other headers) to include/llvm/<directory>, rather than an llvm
directory inside of win32. Manually copying those files into the main
"include" directory seems to work, anyway, and the files that I had there
before seemed to be the ones from the Cygwin build I ran earlier using
configure. (Perhaps there needs to be a "configure.bat" that does that same
kinds of things?)
When trying to build System, then, I get the "Cannot find windows.h" error
from DynamicLibrary.cpp. Insofar as I have a stock VS 2005 install, it's
right--windows.h isn't part of the standard VC/include directory; it's
tucked away in the "VC/PlatformSDK/include" directory, and the .sln doesn't
seem to explicitly reference this (though it really shouldn't have to,
IIRC). When I add this to the project settings for System, it builds
I haven't gotten beyond this for the moment just because I want to get this
sent off and see what the responses are before I start hacking harder on the
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing