similar to: [LLVMdev] Re: LLVM Visual Studio Project files

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

Two suggestions: 1. m4 might be located by your PATH variable. 2. Talk to Morten Ofstad about how he got it to work. Reid. On Wed, 2004-11-03 at 19:34, Jeff Cohen wrote: > 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

I'll try and verify it later tonight. On Wed, 03 Nov 2004 08:18:51 -0800 Reid Spencer <reid at x10sys.com> wrote: > 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,

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. On Thu, 04 Nov 2004 18:45:18 -0800 Reid Spencer <reid at x10sys.com> wrote: > Two suggestions: > > 1. m4 might be located by your PATH variable. > 2. Talk to Morten Ofstad about how he got it to work. > > Reid. > > On

We could also do the "cvs admin -kb" thing on all the project files so that cvs won't do keyword expansion or line ending conversion. Thoughts? Reid. On Mon, 2004-11-08 at 07:36, Jeff Cohen wrote: > You have to use a version of CVS that's specifically built for Windows. > You can find prebuilt Windows binaries at cvshome.org. The cygwin > supplied CVS no doubt

Morten Ofstad wrote: > Jeff Cohen wrote: > >> The recent issues concern the head revision, post 1.9. As no one has >> ever submitted patches to fix 2005 problems with the 1.9 release, it is >> safe to say they still exist. >> > > For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails

Jeff Cohen wrote: > Morten Ofstad wrote: >> Jeff Cohen wrote: >> >>> The recent issues concern the head revision, post 1.9. As no one has >>> ever submitted patches to fix 2005 problems with the 1.9 release, it is >>> safe to say they still exist. >>> >> >> For the 1.5 release I submitted patches that made everything compile

You have to use a version of CVS that's specifically built for Windows. You can find prebuilt Windows binaries at cvshome.org. The cygwin supplied CVS no doubt thinks it's running on Unix, so naturally it won't convert line endings. On Mon, 08 Nov 2004 16:23:30 +0100 Morten Ofstad <morten at hue.no> wrote: > Jeff Cohen wrote: > > > Are you sure your CVS is

I have some patches of my own: * An improvement on Morten's fix to Signals.cpp. * Undo the breakage to system.vcproj (Signals.cpp was being built twice as a result). * Fix a class/struct inconsistency. * Remove unneeded #includes from win32 fSystem files. I've also determined why VC++ complains about deprecated destructors when using hash_map. Because it's not ANSI (yet),

We could add the MSVS project files to the repository but I too would like to see a single mechanism for building on all platforms. Someone mentioned using the Boost build system a few weeks ago but I haven't heard anything more on how that effort is going. I also think we can customize our existing makefiles to use the underlying (command oriented) tools under MSVS. We'd still need

Jeff Cohen wrote: > The recent issues concern the head revision, post 1.9. As no one has > ever submitted patches to fix 2005 problems with the 1.9 release, it is > safe to say they still exist. For the 1.5 release I submitted patches that made everything compile correctly with VS2005, I think there are some mails in the archives about the issues I ran into. I also submitted patches

On Mon, 1 Nov 2004, Morten Ofstad wrote: > with the patches you accepted last week, everything now works with two > one-line modifications. Great! > One is a missing include in a windows specific > platform file and Okay, as Jeff pointed out, this isn't needed, so not applied. > the other is a definition of a symbol I need to trick the linker (as > discussed before)...

ltdl.h fully supports windows platforms (lots of them). That isn't the issue. The issue is setting up the #defines to reflect the windows system. e.g. HAVE_DLOPEN needs to be false Reid. On Fri, 2004-12-03 at 20:35, Chris Lattner wrote: > On Fri, 3 Dec 2004, Jeff Cohen wrote: > > > It will have to be Morten. I can't get ltdl.c to compile. But wasn't > > the

I finally succeded in compiling TableGen with Visual Studio. In the end I made normal solution and project files for VS instead of using Paolo's SConstruct based build system because of my lacking familiarity with SConstruct. One of the main obstacles was getting the FileLexer and FileParser to build correctly. First of all the output file for FileLexer is specified with a %option, which

Jeff Cohen wrote: > Are you sure your CVS is configured correctly? On Windows, CVS > automatically converts between LF and CR/LF line endings. I sent a > patch to remove all CRs from the repository because when I checked out > the files on Windows, every line had two CRs and a single LF. When VS > saved a modified project file, the extra CR went away, causing every > line to

I moved my own llvm tree out of the way and tried to get a fresh copy from cvs and build everything from scratch... and it worked! apart from one little problem, a file was moved and should be removed from the project files -- here is a patch. There is a small problem with submitting patches for the .vcproj files - VS saves them with CRLF line endings but the CVS versions appear to have only

Morten Ofstad wrote: > > Well, actually I'm speaking mostly for myself ;-) I have a front end, I > want to generate code, all I really need is a llvm.lib and the include > files that go along with it... I imagine this is quite a common > scenario, but I might be wrong. This is pretty much my usage scenario too, however I expect to be *able* to hack on the source and

Well, then why does win32/DynamicLibrary.cpp exist, not to mention it's *nix relatives? You have even been updating them, even though they cannot be compiled as they aren't included by System/DynamicLibrary.cpp. Anyway, with Morten's patches I can almost build successfully. Minor patch attached to fix the residual problems. I don't know why he didn't hit these problems.

Morten Ofstad wrote: >> Hi, >> >> There's no HAVE_RAND48 symbol provided by autoconf. You'll have to >> add the appropriate check to autoconf/configure.ac before we can take >> this patch. I installed autoconf with cygwin now and I think I've managed to do this right now -- there are some strange problems with running the AutoRegen.sh script, so I

Hi Jeff, I'm just reviewing some old mail on my "to do" list. I was wondering if you managed to get ltdl.c to compile cleanly with VC++ or if you want me to look at these warnings. Reid. On Sun, 2004-12-05 at 09:08, Jeff Cohen wrote: > Well, then why does win32/DynamicLibrary.cpp exist, not to mention it's > *nix relatives? You have even been updating them, even though