Is there someone tried LLVM 2.1 on Visual Studio 2005?

Project Infrastructure LLVM Dev List Archives
#1

Thanks for your comment.
I also tried for LLVM 2.2 but got the same compilation errors on VS2005. (I didn't modify anything before the compilation)

I just wonder if I need bison and flex even just in the case of compiling them on VS2005 without changing anything because the LLVM doc says "If you plan to modify any .y or .l files, you will need to have bison and/or flex installed where Visual Studio can find them. Otherwise, you do not need them and the pre-generated files that come with the source tree will be used."

One of errors of mine is as follows:

#2

I have always built it with flex and bison installed, though I believe
Chris removed our last dependence on flex a little while back, so you
may not need that. I'm using bison 2.1 which I got from the getgnuwin32
folks. I imagine that if you have cygwin or the like, you probably
already have everything.

You will need to have the executables in your path.

I build with VisualStudio 2k5 Professional with VStudio SP1 installed.
I typically work on Vista32 or Vista64, but have compiled on XP as well.

I don't know how up to date the LLVM docs related to Visual Studio
compilation are.

Thanks,
Chuck.

#3

I have always built it with flex and bison installed, though I believe
Chris removed our last dependence on flex a little while back, so you
may not need that. I'm using bison 2.1 which I got from the getgnuwin32

I think that llvmc and llvm-upgrade still use flex. Neither of those are really interesting on windows and both are slated to be removed for 2.3.

It would be nice to get help upgrading all the .ll files in llvm/test. Once that happens, we can nuke llvm-upgrade from mainline.

-Chris

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Seung Jae Lee
Sent: Tuesday, February 12, 2008 9:52 PM
To: llvmdev@cs.uiuc.edu
Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio
2005?

Thanks for your comment.
I also tried for LLVM 2.2 but got the same compilation errors on VS2005.
(I didn't modify anything before the compilation)

I just wonder if I need bison and flex even just in the case of
compiling them on VS2005 without changing anything because the LLVM doc
says "If you plan to modify any .y or .l files, you will need to have
bison and/or flex installed where Visual Studio can find them.
Otherwise, you do not need them and the pre-generated files that come
with the source tree will be used."

One of errors of mine is as follows:
-------------------------------------------------------
...
7>llvmAsmParser.cpp
7>c1xx : fatal error C1083: Cannot open source file:
'.\llvmAsmParser.cpp': No such file or directory
...
-------------------------------------------------------
where llvmAsmParser.cpp is related to Bison so I am compelled to feel to
try installing flex/bison on my machine, anyway.

Forgive my ignorance, could you briefly tell me about that?
Thank you in advance.

Seung

Date: Tue, 12 Feb 2008 18:20:59 -0800
From: "Chuck Rose III" <cfr@adobe.com>
Subject: Re: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio

2005?

To: "LLVM Developers Mailing List" <llvmdev@cs.uiuc.edu>

Hola Seung,

I don't know if 2.1 in particular worked. I updated the 2.2 win32
vstudio 2k5 files right before lockdown, so they should be building.
You will need appropriate versions of flex and bison installed. I used
the ones from getgnuwin32 on my machine.

Good luck.

Chuck.

From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu]
On Behalf Of Seung Jae Lee
Sent: Monday, February 11, 2008 10:05 PM
To: llvmdev@cs.uiuc.edu
Subject: [LLVMdev] Is there someone tried LLVM 2.1 on Visual Studio
2005?

Hello all,

Is there anyone has tried LLVM 2.1 on Visual Studio 2005?
I did but not succeed due to some build errors.
I seem to remember I read somewhere on this list it's compiled on

VS2005

so I wonder...
Have a good night.

Thx,
Seung
_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

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

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

-Chris

#4

I have flex and bison from Cygwin installed:

$ flex --version
flex version 2.5.4

$ bison --version
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Should that work, assuming they're on the PATH? When I ran the build from
inside VS, I get some build failures, but nothing that implies that it was
looking for flex/bison to execute directly--are you supposed to run these
prior to launching the build?

The docs on "Getting Started with Visual Studio" seem a tad bit out of date,
but I'm certainly not enough beyond n00b status to know for sure.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

#5

I have flex and bison from Cygwin installed:

WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio.

    http://gnuwin32.sourceforge.net/

The LLVM Visual Studio .sln file is for Visual Studio 2003 so will require conversion and some minor modification.

Aaron

#6

>I have flex and bison from Cygwin installed:

WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio.

   http://gnuwin32.sourceforge.net/

Oh, you will have to install WinGNU32 M4 too.

Aaron

#7

I converted it over to 2k5 a while back. Don't know about the 2.1 drop,
but definitely for the 2.2 drop and most of the trunk time in between.

On Behalf Of Aaron Gray

#8

>I have flex and bison from Cygwin installed:

WinGNU32 Flex and Bison are the ones to use with LLVM and Visual Studio.

   http://gnuwin32.sourceforge.net/

Oh, you will have to install WinGNU32 M4 too.

Aaron

#9

By the way, somebody (I think it was Chuck, but I don't remember for
certain) was asking for the BuildLog.htm from building the llvm.sln file
under VS 2005 SP1 for diagnostic purposes; right now the SLN is configured
to produce a new BuildLog for each and every one of the projects inside the
solution. I don't know who's responsible for this guy, but that's probably
not the best way to do this.

Chuck (assuming it was you), would it not be easier for me to capture the
full results of an "msbuild llvm.sln" from the console for you?

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

#10

More on this:

Walking through the projects slowly:

(*) "Configure" builds with no problem.
(*) "support" fails:

C:\Prg\llvm-2.2\llvm-2.2\win32>msbuild llvm.sln /t:Build
Microsoft (R) Build Engine Version 2.0.50727.1433
[Microsoft .NET Framework, Version 2.0.50727.1433]
Copyright (C) Microsoft Corporation 2005. All rights reserved.

Build started 2/18/2008 12:07:45 AM.

#11

There's a config.h file in the win32 subdirectory that implies that

it's

supposed to be concatenated as part of the build process, but it

doesn't

seem like that's happening from within the .sln script--am I missing a
pre-build step someplace?

When config.h.in is hit in the build of configure the configure project,
the configure.h file from the win32 directory is copied to main
llvm\Config\Config.h. The script in the sln file is:

copy "$(InputPath)"+"$(SolutionDir)config.h"
"$(ProjectDir)..\llvm\Config\config.h"

configured as a custom build step in the solution file. Is that not
firing from the command line compilation of the sln?

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
configure. We should probably be doing something more clever here.

Thanks,
Chuck.

#12

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
did, faithfully.

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\\"
/Fd"\bin\Win32\Debug\support.pdb
" /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
configure.

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?)

Moving onwards...

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
cleanly.

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
project settings.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

#13

OK, a couple of things aren't parsing here.

When config.h.in is hit in the build of configure the configure
project,
the configure.h file from the win32 directory is copied to main
llvm\Config\Config.h. The script in the sln file is:

There is no "configure.h" file from the win32 directory; there is a
config.h, and it's 600 bytes long, compared to the 16k or so for the
config.h file in $LLVM-ROOT/include/llvm/Config. The contents are obviously
different, as well, since the one in $LLVM-ROOT/include/llvm/Config has the
LLVM_ON_UNIX #define set.

It didn't appear to be doing the copy even when building from within VS.
Using "vcbuild /clean" then "vcbuild" on the Configure.vcproj file directly
seems to have forced the copy to take place. I can see the "1 file(s)
copied" output in the BuildLog.

Except it doesn’t. File date/time reveals that nothing's been done to it,
and opening it up confirms that the win32\config.h isn't appended.

For whatever reason, only by manually deleting the config.h file in the
llvm/include/Config directory can I get the project to re-gen that config.h
file. I'm not sure if this is a property of running the build from the
command-line (but I'm guessing it's not, since MSBuild is used internally
inside VS), or if the file-copy is being prevented by something in my
environment (files are marked writable, I already checked).

I don't know if you need to be "more clever" here, since MSBuild is fully
capable of doing what you're trying to get it to do--I have no idea why
those file copies appear to be failing. Can you double-check and make sure
they're working correctly on your machine? That way we know it's a
peculiarity of my setup and not something intrinsic inside the build script.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com

#14

For whatever reason, only by manually deleting the config.h file in the
llvm/include/Config directory can I get the project to re-gen that config.h
file. I'm not sure if this is a property of running the build from the
command-line (but I'm guessing it's not, since MSBuild is used internally
inside VS), or if the file-copy is being prevented by something in my
environment (files are marked writable, I already checked).

The MSBuild infrastructure isn't used by VS 2005 for C++ projects;
rather, VCBuild does the work. I'm not sure about VS 2008.

FWIW, I used ProcMon to diagnose file-handling issues I had in my build:

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

-- Barry

#15

True, but MSBuild is what's invoked for a Solution, which then defers to
VCBuild, as I understand it. (The rumor is that the C++/CLI team was so busy
revamping the Managed C++ language for Whidby that they had no time to adapt
MSBuild to building C++ apps. *shrug*)

Regardless, as I mentioned in the follow-up email, the files *are* being
copied, just not where I expected them to end up, which I think is a bug in
the .sln/.vcproj files.

Ted Neward
Java, .NET, XML Services
Consulting, Teaching, Speaking, Writing
http://www.tedneward.com