The Visual Studio project files that Morten Ofstad provided have been committed to CVS in the win32 directory. I would appreciate it if Morten and at least one other win32 developer could verify that the files work correctly as committed.
Thanks,
Reid.
I'll try and verify it later tonight.
I have problems getting the GNU tools to execute properly. I installed
bison, sed, and flex from gnuwin32.sourceforge.net as suggested in the
README. The installers for these packages did not want to put them in
the llvm/win32/{tools,share} directory, which is unfortunately where the
project files expect them to be. I copied the files manually to these
directories, but bison still refuses to work. I get:
..\tools\bison: m4: No such file or directory
m4.exe is present in the same directory as bison. I don't know where
bison expects to find it. I know where it would expect to find it on
Unix, but that directory does not exist on a Windows system. Yes, m4.exe
is in the path, but that's not good enough for bison. It's also present
where their installer put it; that's not good enough either.
Sigh... this is precisely why I hate using GNU software under Windows,
because gotchas like this keep happening. I suppose I can always build
my own binaries from the sources; that would solve the problem if
nothing else will... once I figure out how bison locates m4... but not
tonight.
Two suggestions:
1. m4 might be located by your PATH variable.
2. Talk to Morten Ofstad about how he got it to work.
Reid.
Like I said, it is in my path. That's not enough. I'd be happy if
Morten chimed in with any suggestions as to how he got it to work.
Solved it. Looking at the source of bison, I found an undocumented
environment variable M4 that points to the m4 binary. Setting it to the
absolute path did the job. When not present, it ought to find it in the
path as it uses execvp. At least on Unix. I have no idea what it does
on Windows as I could not get the source used to build the Windows
version (the installer claimed it installed the source, but it didn't).
The link of tablegen fails still fails, though, complaining of a missing
support.lib. This is due to a bug in the debug configuration of
tablegen (and is not present in the release configuration). Patch
attached.
Watching this thing build, what comes to mind is that it would go a
whole lot faster if we could use precompiled header files.
Unfortunately, there's no way to do this with VC++ without modifying
every *.cpp file. On the other hand, doesn't gcc support precompiled
header files also? Not that it necessarily does it in even remotely the
same way...
The build finally gets to Fibonacci and fails with:
c:\llvm\examples\Fibonacci\fibonacci.cpp(111) : error C2065: 'args' : undeclared identifier
c:\llvm\examples\Fibonacci\fibonacci.cpp(111) : error C2228: left of '.IntVal' must have class/struct/union type
I don't how this compiles with gcc. "args" is mispelled. Should be
"Args". Patch attached for this also.
Also, the llvm.suo file should not be in the repository. This has
per-user configuration settings for VS. I'm surprised you even knew it
was there to be checked in, as it's a hidden file. This file had
hard-coded paths to Morten's setup, and even had his breakpoints in it.
So... once these problems are fixed, I run fibonacci and get the
following output:
win.diffs (1.18 KB)
path as it uses execvp. At least on Unix. I have no idea what it does
on Windows as I could not get the source used to build the Windows
version (the installer claimed it installed the source, but it didn't).
Wierd.
The link of tablegen fails still fails, though, complaining of a missing
support.lib. This is due to a bug in the debug configuration of
tablegen (and is not present in the release configuration). Patch
attached.
Ok, applied, thanks!
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020249.html
Watching this thing build, what comes to mind is that it would go a
whole lot faster if we could use precompiled header files.
I don't know of a good way to do that. Personally, I'm a big fan of just
putting as little into #includes as possible, instead of relying on PCH.
The build finally gets to Fibonacci and fails with:
c:\llvm\examples\Fibonacci\fibonacci.cpp(111) : error C2065: 'args' : undeclared identifier
c:\llvm\examples\Fibonacci\fibonacci.cpp(111) : error C2228: left of '.IntVal' must have class/struct/union typeI don't how this compiles with gcc. "args" is mispelled. Should be
"Args". Patch attached for this also.
This was a transient bug in CVS that you must have just been unlucky to
get, sorry about that.
Also, the llvm.suo file should not be in the repository. This has
per-user configuration settings for VS. I'm surprised you even knew it
was there to be checked in, as it's a hidden file. This file had
hard-coded paths to Morten's setup, and even had his breakpoints in it.
Ok, nuked.
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020250.html
starting fibonacci(10) with JIT...
Result: 55
I assume this is correct.
Yup, this is right! Does this mean that you guys don't need the hack to
pull in the X86 backend by force on Win32?
-Chris
> Also, the llvm.suo file should not be in the repository. This has
> per-user configuration settings for VS. I'm surprised you even knew it
> was there to be checked in, as it's a hidden file. This file had
> hard-coded paths to Morten's setup, and even had his breakpoints in it.Ok, nuked.
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020250.html
And not to be picky, but all the debug/release directories ought to be
nuked also. No files will ever be checked in these directories, and cvs
won't even create them on checkout because they are empty. VS will
happily create them when needed.
> starting fibonacci(10) with JIT...
> Result: 55
> I assume this is correct.Yup, this is right! Does this mean that you guys don't need the hack to
pull in the X86 backend by force on Win32?
Morten will have to answer this one.
-Chris
I'm attaching the build log from VS. There are several dozen
compilation warnings that you may or may not want to fix.
build.log (24 KB)
And not to be picky, but all the debug/release directories ought to be
nuked also. No files will ever be checked in these directories, and cvs
won't even create them on checkout because they are empty. VS will
happily create them when needed.
Done.
> > starting fibonacci(10) with JIT...
> > Result: 55
> > I assume this is correct.
>
> Yup, this is right! Does this mean that you guys don't need the hack to
> pull in the X86 backend by force on Win32?Morten will have to answer this one.
ok.
I'm attaching the build log from VS. There are several dozen
compilation warnings that you may or may not want to fix.
I fixed a bunch of them, see the llvm-commits list. I don't agree with
the whole "lets warn if you negate an unsigned number" warning, and I
don't know what to do about deprecated hash_map and friends, but most of
the rest are fixed.
-Chris
First of all, I've been working at the university for a few days, so I haven't read my hue.no email -- sorry I wasn't there to help when you tried to use my project files. But it seems it turned out well, thanks a lot to Jeff Cohen for cleaning up my mess!
First of all, the gnu tools -- I copied them into the llvm/win32 directory from the original (default) installation location because I did not want any absolute paths in the project files. I also don't want the project to pull in any old flex or bison along the path, since I have cygwin in my path. The readme.txt is missing some details on how to install these tools because the first archive I sent to Reid had all the tools in it. I'm happy Jeff sorted it out, but it would be nice if he could also write some instructions in the readme on how he did it.
The link of tablegen fails still fails, though, complaining of a missing
support.lib. This is due to a bug in the debug configuration of
tablegen (and is not present in the release configuration). Patch
attached.
This is a bit strange, it was building fine on my system... Anyway, thanks for the fix.
Yup, this is right! Does this mean that you guys don't need the hack to
pull in the X86 backend by force on Win32?
There is a forced symbol reference in the fibonacci project files to pull in the x86 backend. If you leave this one out, it still works because it uses the interpreter instead - but of course it's 100 times slower...
m.