similar to: [LLVMdev] Final Visual Studio Patches

On Tue, 02 Nov 2004 10:25:39 +0100 "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > I've come over an open source script which should be able to convert unix > (gnu?) like makefiles to nmake. However, It possible needs some changes to > work with the llvm makefile framework. I'm very doubtful this utility is of any use. nmake is useless compared to gnu

Jeff Cohen wrote: > On Tue, 02 Nov 2004 10:25:39 +0100 > "Henrik Bach" <henrik_bach_llvm at hotmail.com> wrote: > > >>I've come over an open source script which should be able to convert unix >>(gnu?) like makefiles to nmake. However, It possible needs some changes to >>work with the llvm makefile framework. > > > I'm very

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

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

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

Then, there is only one solution left as suggested by Reid. Count me in... Henrik ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] Final Visual Studio Patches Date: Tue, 2 Nov 2004 07:16:53 -0800 On Tue, 02

On Nov 2, 2004, at 8:38 AM, Reid Spencer wrote: > 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

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

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,

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

> Right. This is why I suggested we just put the project files in a simple > place that Windows folks can keep up to date and that won't get in the > way of the Unix folks. I have them in llvm/win32 ... There is another solution though, you could require cygwin to be installed and use the unix build system but with the VS command line tools. The 'check' target should be

> It's close to irrelevant when they last worked at this point - the current > stable release series is 1.4.x, and they definitely won't work with that. acknowledged Visual Studio 2008, win32 makefiles (from C. Hull's website) and xapian-core-1.2.8 are mentioned together on this webpage https://lists.xapian.org/pipermail/xapian-devel/2012-October/001883.html

What's wrong with a plain old .bat file, or even an NMAKE .mak file? Ship two files, debug.bat and release.bat, and call it good. It is best to leave project-file creation up to individual users, in my opinion. MS changes their IDEs and project-file formats more often than most people change their underwear. The odds that any given open-source project will actually compile without any

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

On Nov 2, 2004, at 2:40 AM, Morten Ofstad wrote: > 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.

Keith Kyzivat a ?crit : > Something to look into perhaps is Trolltech's 'qmake' tool. > It fills the role of something like autotools or now defunct imake. I think TrollTech deserves a prize for their accomplishment in making qmake even worse than autotools (I'm using it for something else and wish I wasn't -- Qt itself is fine though). I've heard good things about

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. On Mon, 01 Nov 2004 11:14:18 +0100 Morten Ofstad <morten at hue.no> wrote: > Hello,

On Tue, 2 Nov 2004, Morten Ofstad wrote: > > Right. This is why I suggested we just put the project files in a simple > > place that Windows folks can keep up to date and that won't get in the > > way of the Unix folks. > > I have them in llvm/win32 ... There is another solution though, you That sounds good. > could require cygwin to be installed and use the unix

>>could require cygwin to be installed and use the unix build system but >>with the VS command line tools. The 'check' target should be useful to >>windows developers also, but it can't be done easily with visual studio >>project files... >Yeah, I think that's what reid was saying. In theory this shouldn't be >too hard, but in practice, who

Hi guys. I recently stumbled on an unexpected behavior of R when using functions created in a loop. The problem is silly enough to me that I had hard time choosing a good mail subject, not talking about searching in the archives... After some experiments, I trimmed down the following minimal reproducible example: ####### makeF <- function(i) function() i fList <- list(makeF(1), makeF(2))