Final Visual Studio Patches

Hello,

with the patches you accepted last week, everything now works with two one-line modifications. One is a missing include in a windows specific platform file and the other is a definition of a symbol I need to trick the linker (as discussed before)... The attached file is the complete diff between my version and the CVS.

If you want to put my visual studio project files into the CVS, please tell me where to send them as they're too big to attach to this mail.

m.

diff.txt (1.84 KB)

If you're getting this error in lib/System/Win32/TimeValue.cpp, then you are not building it correctly. This file is included by lib/System/TimeValue.cpp, which is what you ought to be building. None of the files under Win32 are to be compiled directly; they are all included by files in lib/System.

Jeff Cohen wrote:

If you're getting this error in lib/System/Win32/TimeValue.cpp, then you are not building it correctly. This file is included by lib/System/TimeValue.cpp, which is what you ought to be building. None of the files under Win32 are to be compiled directly; they are all included by files in lib/System.

I probably was building it incorrectly at some point -- now I just removed this line and everything is still working... Sorry for any trouble...

m.

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)... The attached file is the complete diff between my

Applied:
http://mail.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20041101/020124.html

If you want to put my visual studio project files into the CVS, please
tell me where to send them as they're too big to attach to this mail.

I'm not sure what the right thing is to do with these, I will defer to
other people more involved with the build to decide.

For me, coming up with a way to support both unix-like and windows-like
systems in one framework seems best from the maintenance standpoint, but I
don't know what the right way is to do this.

-Chris

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 cygwin for this solution but at least we could compile with an MS compiler.

Reid.

Chris Lattner wrote:

While a single mechanism is best in principle, it *is* possible to come up with one so complicated or unfamiliar that it is harder to use on all platforms. The Windows and *nix development worlds seem different enough that there is a risk of ending up like this. I'm not objecting to trying to create a unified build system, but I think it's worth considering whether the result will actually be better than 2 separate systems (which we already now have, thanks to Morten's and others' efforts).

Another alternative may be to unify the LLVM-side information (opt/debug options, tool names, directories, test scripts, etc.) so that most tasks only require you to make changes in one place, and then let the rest of the build system be separate for the two platforms.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

Vikram S. Adve wrote:

Another alternative may be to unify the LLVM-side information (opt/debug options, tool names, directories, test scripts, etc.) so that most tasks only require you to make changes in one place, and then let the rest of the build system be separate for the two platforms.

I think it's OK to have a seperate limited (only the core libraries) native build for Visual Studio, and use the Unix build system for all the more advanced tasks. It should be possible to build under Cygwin but using the MS command line tools. Windows users are generally fond of binary distributions anyway, so it doesn't really matter much if it's a bit involved to build everything from the sources.

My port only includes the core llvm libraries, tablegen and the fibonacci example. None of the tools or compiler front ends have been built, just enough to generate code dynamically. I still had to use the gnuwin32 ports of sed, flex and bison to get it working, so it requires some external tools but nothing as big as the full cygwin32 install...

Anyway, if anyone wants the VS project files just contact me. It's really a separate thing from the main project so I can see why you're reluctant to put it in the CVS. And, as said before, I think most windows users would prefer a binary distribution anyway so the ease of building the windows version from source is largely irrelevant.

m.

Vikram S. Adve wrote:

Another alternative may be to unify the LLVM-side information (opt/debug options, tool names, directories, test scripts, etc.) so that most tasks only require you to make changes in one place, and then let the rest of the build system be separate for the two platforms.

I think it's OK to have a seperate limited (only the core libraries) native build for Visual Studio, and use the Unix build system for all the more advanced tasks.

I don't really know enough about VS builds to give an opinion on this, except to say that unifying the harder tasks will probably require significant changes to the common makefiles anyway. But the build system gurus should be the ones to decide this.

It should be possible to build under Cygwin but using the MS command line tools. Windows users are generally fond of binary distributions anyway, so it doesn't really matter much if it's a bit involved to build everything from the sources.

My port only includes the core llvm libraries, tablegen and the fibonacci example. None of the tools or compiler front ends have been built, just enough to generate code dynamically. I still had to use the gnuwin32 ports of sed, flex and bison to get it working, so it requires some external tools but nothing as big as the full cygwin32 install...

Anyway, if anyone wants the VS project files just contact me. It's really a separate thing from the main project so I can see why you're reluctant to put it in the CVS. And, as said before, I think most windows users would prefer a binary distribution anyway so the ease of building the windows version from source is largely irrelevant.

Are you referring to compiler writers or compiler *users*? I can see binary distributions working for the latter but not the former.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

Vikram Adve wrote:

Anyway, if anyone wants the VS project files just contact me. It's really a separate thing from the main project so I can see why you're reluctant to put it in the CVS. And, as said before, I think most windows users would prefer a binary distribution anyway so the ease of building the windows version from source is largely irrelevant.

Are you referring to compiler writers or compiler *users*? I can see binary distributions working for the latter but not the former.

Well, actually I'm speaking mostly for myself :wink: 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.

m.

Morten Ofstad wrote:

Well, actually I'm speaking mostly for myself :wink: 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 consequently rebuild it if I need too. Furthermore, a large part of the usage of LLVM is currently in research where modifications are much more likely.

It sounds like there are two primary usage models, however:

1. I-just-need-a-backend-to-generate-code case:
    Here a simple binary distribution (tools, libraries, headers) would be
    sufficient.

2. I-need-to-hack-a-compiler-for-my-work/research case:
    Here the user needs full build control over everything (we can't pre-suppose
    which part of LLVM they want to hack on).

So, I think what we want is a full build environment anyway to satisfy case 2 and generate the binary distribution for case 1. Ideally what we want is a build system that can produce an msi installer on windows, rpms on RH, Solaris pkg on Sun, StuffIt on Mac (or whatever they use these days). However, tgz or zip is probably sufficient for binary distributions for a while.

My point here is that we have 98% of what we need for *all* Unix platforms, the only missing link is Windows. So, why should we bastardize both worlds? Attempting windows conformance in the makefiles will make the Unix world unhappy. Attempting to unixify a windows build environment would make the windows world unhappy. My vote is to just have both an MSVS project file and other supporting files added to a directory named "win" at the top level and let the windows folks keep it up to date. That way everyone is happy :slight_smile:

Reid.

All of this makes sense to me.

--Vikram
http://www.cs.uiuc.edu/~vadve
http://llvm.cs.uiuc.edu/

Me too.