llvm dev - Dec 2004 - [LLVMdev] VC++: Cannot open include file: 'windows.h':No suchfileor directory

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----
From: Jeff Cohen <jeffc at jolt-lang.org>
Reply-To: jeffc at jolt-lang.org,        LLVM Developers Mailing List 
<llvmdev at cs.uiuc.edu>
To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] VC++: Cannot open include file: 
'windows.h':No	suchfileor directory
Date: Thu, 23 Dec 2004 08:40:13 -0800

Henrik Bach wrote:
>----Original Message Follows----
>From: Jeff Cohen <jeffc at jolt-lang.org>
>Reply-To: jeffc at jolt-lang.org,        LLVM Developers Mailing List 
><llvmdev at cs.uiuc.edu>
>To: LLVM Developers Mailing List <llvmdev at 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.

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

_________________________________________________________________
Del din verden med MSN Spaces  http://spaces.msn.com

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:
> 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----
> From: Jeff Cohen <jeffc at jolt-lang.org>
> Reply-To: jeffc at jolt-lang.org,        LLVM Developers Mailing List 
> <llvmdev at cs.uiuc.edu>
> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Subject: Re: [LLVMdev] VC++: Cannot open include file: 
> 'windows.h':No    suchfileor directory
> Date: Thu, 23 Dec 2004 08:40:13 -0800
>
> Henrik Bach wrote:
>
>> ----Original Message Follows----
>> From: Jeff Cohen <jeffc at jolt-lang.org>
>> Reply-To: jeffc at jolt-lang.org,        LLVM Developers Mailing List 
>> <llvmdev at cs.uiuc.edu>
>> To: LLVM Developers Mailing List <llvmdev at 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.
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _________________________________________________________________
> Del din verden med MSN Spaces  http://spaces.msn.com
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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----
From: Jeff Cohen <jeffc at jolt-lang.org>
Date: Sat, 25 Dec 2004 16:28:40 -0800

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:
>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----
>From: Jeff Cohen <jeffc at jolt-lang.org>
>Reply-To: jeffc at jolt-lang.org,        LLVM Developers Mailing List 
><llvmdev at cs.uiuc.edu>
>To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
>Subject: Re: [LLVMdev] VC++: Cannot open include file:
'windows.h':No
>suchfileor directory
>Date: Thu, 23 Dec 2004 08:40:13 -0800
>
>Henrik Bach wrote:
>
>>----Original Message Follows----
>>From: Jeff Cohen <jeffc at jolt-lang.org>
>>Reply-To: jeffc at jolt-lang.org,        LLVM Developers Mailing List 
>><llvmdev at cs.uiuc.edu>
>>To: LLVM Developers Mailing List <llvmdev at 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.
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>_________________________________________________________________
>Del din verden med MSN Spaces  http://spaces.msn.com
>
>_______________________________________________
>LLVM Developers mailing list
>LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

_________________________________________________________________
Find det, du s�ger p� MSN S�g http://search.msn.dk