llvm dev - May 2008 - [LLVMdev] VS build is broken again

Ted,

Thanks for taking care of this.  I found that in order to build clang
(in addition to the vcproj changes I posted earlier today) I had to add
a dependency such that the clangDriver project depends on the CodeGen
(basically the CodeGen checkbox has to be checked in the list of the
clangDriver's dependencies).  This in effect adds codegen.lib to the
list of libraries linked into clang.exe and solves all the unresolved
symbol errors in the clang build.  I would submit the diff, but it
looks like visual studio changes all the encodings of projects in the
.sln file, so the diff includes a lot of irrelevant lines.

Thanks
Dmitri

--- Ted Kremenek <kremenek at apple.com> wrote:
> 
> On May 17, 2008, at 10:04 PM, Dmitri Makarov wrote:
> 
> > If I'm not mistaken about a week ago llvm.sln used to be VS 2008
> > version and now it's VS 2005 again.  I don't follow the llvm
lists
> too
> > close to know what happened. So, really, what's going on with the
> VS
> > build?  Clang.sln has always been VS 2005. All this is frustrating.
> 
> 
> I find it frustrating as well.  Here is my understanding of the  
> situation.
> 
> One of the clang contributors upgraded the project file to VS 2008.  
> 
> Another clang contributor (who is also an Apple employee) is using VS
>  
> 2005 (but not VS 2008) to build clang on Windows, and decided to  
> revert the patch upgrading the VS project files to 2008.  However, I 
> 
> imagine the project files were upgraded for a reason, i.e., the build
>  
> was broken, but the person who reverted the patch I believe did not
> go  
> ahead and upgrade the project files on VS 2005.  This is at least my 
> 
> interpretation of the situation.  I'm trying to find out what the  
> exact status of the build (both LLVM and clang) is on VS 2005, and
> get  
> the situation straightened out.
> 
> The main problem is that there is no regular maintainer of the LLVM/ 
> clang build on VS, and we want to keep the project files using VS  
> 2005, not VS 2008.
>

On May 17, 2008, at 11:51 PM, Dmitri Makarov wrote:
> This in effect adds codegen.lib to the
> list of libraries linked into clang.exe and solves all the unresolved
> symbol errors in the clang build.  I would submit the diff, but it
> looks like visual studio changes all the encodings of projects in the
> .sln file, so the diff includes a lot of irrelevant lines.
Changes all the encodings?  Does this have to do with locale settings?

If you look at an .sln file, there's a long sequence of digits
associated with every project, something like this
8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942. For the lack of a better word I
called it "encoding".  After I changed the dependencies between
projects in the solution, msvs replaced those numeric sequences by new
ones literally for every project in the solution file. The diff now
includes all such changes of numeric sequences associated with each
project, which are not really relevant to the problem at all.  I don't
think it matters and would work for anyone equally well, but
nevertheless not to confuse you with such a large diff, I think it's
better if someone on your site would just add the dependency I
mentioned before and would check-in his .sln file.

--- Ted Kremenek <kremenek at apple.com> wrote:
> 
> On May 17, 2008, at 11:51 PM, Dmitri Makarov wrote:
> 
> > This in effect adds codegen.lib to the
> > list of libraries linked into clang.exe and solves all the
> unresolved
> > symbol errors in the clang build.  I would submit the diff, but it
> > looks like visual studio changes all the encodings of projects in
> the
> > .sln file, so the diff includes a lot of irrelevant lines.
> 
> Changes all the encodings?  Does this have to do with locale
> settings?
>