VC++: Cannot open include file: 'windows.h': No such file or directory

Hi,

I cannot find windows either... In previous llvm sources windows.h was found in: 'include/llvm/Config'.

------ Build started: Project: support, Configuration: Release Win32 ------
Compiling...
randtable.c
c:\projects\src\llvm-1\llvm\lib\Support\bzip2\bzlib.h(117) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
huffman.c

Windows.h is part of Microsoft's Platform SDK that's bundled with Visual Studio. It should never have been in the llvm source tree. Why don't you have it? You have VC++, right?

Henrik Bach wrote:

bzlib.h does not include "llvm/Config/windows.h" it just includes
"windows.h". If that header can't be found then the vcproj settings to
build bzip2 are incorrect.

Reid.

----Original Message Follows----

Yes, it should find windows.h with the default configuration. But you have to be suspicious of beta code that Microsoft gives out for free. It might just be very buggy, or it might be deliberately crippled. Considering the price tag on Visual Studio, it's one or the other (and probably both).

Out of curiosity, did it accept the solution and project files as is, or did it want to "upgrade" them? If the latter, I cannot accept any patches for those files because they would break VC++ 7.1 (which in turn broke 7.0, which in turn broke 6.x).

Henrik Bach wrote:

----Original Message Follows----

Henrik Bach wrote:

----Original Message Follows----
From: Jeff Cohen <jeffc@jolt-lang.org>
Reply-To: jeffc@jolt-lang.org, LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
To: LLVM Developers Mailing List <llvmdev@cs.uiuc.edu>
Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory
Date: Thu, 23 Dec 2004 08:05:39 -0800

Out of curiosity, did it accept the solution and project files as is, or did it want to "upgrade" >them? If the latter, I cannot accept any patches for those files because they would break VC++ >7.1 (which in turn broke 7.0, which in turn broke 6.x).

No, it didn't take the project files out of the box. It insisted to upgrade the soulution and project files.

Henrik.

Groan... it's bad enough they keep breaking backwards compatibility, but what's much worse is that the upgrade is never 100% correct. Builds are broken in subtle and hard to track down ways. It's why VS upgrades get put off for as long as possible. I won't even think of upgrading to Whidbey until several years after its release.

Hopefully you won't have to. By then LLVM and XPS should be a suitable
replacement :slight_smile:

Reid.

Reid Spencer wrote:

Hi Jeff and Morten,

I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool?

This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other.

Henrik.

----Original Message Follows----

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS.

There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be amazed at the amount of commercial Windows software development that still uses VC++ 6.0 even today. And that's with 7.1 offering real advantages to C++ programmers over 7.0, which itself had real advantages over 6.0. I've yet to see anything for us in 8.0. I can't imagine upgrading before 8.1 or even 9.0, and then with reluctance.

Henrik Bach wrote:

I agree completely with you, Jeff.

However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk).

And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC 6.0 to future releases.

Another future solution could be that the VC++ x tools get incorparted into the makefile structure, as previously discussed. It appeared to me that the mingw or gunwin32 environment mixed with the VC++ x tools could be a solution.

Henrik.

----Original Message Follows----

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS.

There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be amazed at the amount of commercial Windows software development that still uses VC++ 6.0 even today. And that's with 7.1 offering real advantages to C++ programmers over 7.0, which itself had real advantages over 6.0. I've yet to see anything for us in 8.0. I can't imagine upgrading before 8.1 or even 9.0, and then with reluctance.

Henrik Bach wrote:

Henrik Bach wrote:

I agree completely with you, Jeff.

However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk).

I've been thinking of writing a "getting started" page for win32.

And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC 6.0 to future releases.

Like I said, multiple "win32" trees would do it, but again what's the rush? There is exactly one version of VC++ that can build LLVM: 7.1. The earlier versions can't compile it at all, and the next version is buggy and unreleased and will remain so for some time.

Another future solution could be that the VC++ x tools get incorparted into the makefile structure, as previously discussed. It appeared to me that the mingw or gunwin32 environment mixed with the VC++ x tools could be a solution.

What problem does this solution solve? If you have the Microsoft toolset, there's no reason to use other toolsets except for specialized stuff like parser generators for which Microsoft does not have a tool. Furthermore, one set of makefiles is simply not going to handle both GNU and Microsoft toolsets. Creating makefiles just for Windows doesn't make much sense as they would only be duplicates of the project files, but minus the powerful features of the VS IDE. I just don't see the benefit.