It would be great to avoid STLPort and use plain vanilla VC... as I told, the biggest difference it's how the hash_map and hash_set are implemented, but I'm not so strong in C++ for resolving the iussue. About the build procedure, it's based on scons, and it's still at a very preliminary stage... Right now I'm trying to build TableGen with it, as till now I've always copied TableGen results from the cygwin build ;-) Gime me a little more time, as I'm in the middle of this, and then I'll post it to the list. --- Paolo Invernizzi BTW... is it that llvm/utils/TableGen/Record.cpp need an include of llvm/Support/DataTypes.h for having the right typedef of int64_t? ;-)) Jeff Cohen wrote:>OK. I strongly support that sentiment. > >Paolo, could you send me your procedure for building under Windows? I >haven't tried to build anything but System/Win32 so far. > > >On Fri, 24 Sep 2004 07:52:23 -0700 >Reid Spencer <reid at x10sys.com> wrote: > > > >>I'll wait for the research. We should try, as much as possible, to make >>it work with just what the compiler provides and without third party >>packages. >>
Uh... this may be a silly question, but why can't you include <stdio.h>? It'd be much better than <iostream>. Anyway, I think I'll try this weekend to come up with my own way of building on Win32. I prefer that building on Windows depends only on Microsoft and GNU tools, and the fewer of the latter the better. My gut instinct is to capture all the files generated by configure on an X86 system, tweak them for Windows and MSVC, then run GNU make and see what happens. Then try and make it actually work :) But I'm likely to give up unless it turns out to be suprisingly easy to do. On Fri, 24 Sep 2004 17:28:54 +0200 Paolo Invernizzi <arathorn at fastwebnet.it> wrote:> It would be great to avoid STLPort and use plain vanilla VC... as I > told, the biggest difference it's how the hash_map and hash_set are > implemented, but I'm not so strong in C++ for resolving the iussue. > > About the build procedure, it's based on scons, and it's still at a very > preliminary stage... > Right now I'm trying to build TableGen with it, as till now I've always > copied TableGen results from the cygwin build ;-) > Gime me a little more time, as I'm in the middle of this, and then I'll > post it to the list. > > --- > Paolo Invernizzi > > BTW... is it that llvm/utils/TableGen/Record.cpp need an include of > llvm/Support/DataTypes.h for having the right typedef of int64_t? > ;-)) > > Jeff Cohen wrote: > > >OK. I strongly support that sentiment. > > > >Paolo, could you send me your procedure for building under Windows? I > >haven't tried to build anything but System/Win32 so far. > > > > > >On Fri, 24 Sep 2004 07:52:23 -0700 > >Reid Spencer <reid at x10sys.com> wrote: > > > > > > > >>I'll wait for the research. We should try, as much as possible, to make > >>it work with just what the compiler provides and without third party > >>packages. > >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
Here's the patch to Signals.cpp. assuming that stdio.h is acceptable (can't imagine it won't work). On Fri, 24 Sep 2004 09:29:05 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote:> Uh... this may be a silly question, but why can't you include <stdio.h>? > It'd be much better than <iostream>. > > Anyway, I think I'll try this weekend to come up with my own way of > building on Win32. I prefer that building on Windows depends only on > Microsoft and GNU tools, and the fewer of the latter the better. > > My gut instinct is to capture all the files generated by configure on an > X86 system, tweak them for Windows and MSVC, then run GNU make and see > what happens. Then try and make it actually work :) But I'm likely to > give up unless it turns out to be suprisingly easy to do. > > > On Fri, 24 Sep 2004 17:28:54 +0200 > Paolo Invernizzi <arathorn at fastwebnet.it> wrote: > > > It would be great to avoid STLPort and use plain vanilla VC... as I > > told, the biggest difference it's how the hash_map and hash_set are > > implemented, but I'm not so strong in C++ for resolving the iussue. > > > > About the build procedure, it's based on scons, and it's still at a very > > preliminary stage... > > Right now I'm trying to build TableGen with it, as till now I've always > > copied TableGen results from the cygwin build ;-) > > Gime me a little more time, as I'm in the middle of this, and then I'll > > post it to the list. > > > > --- > > Paolo Invernizzi > > > > BTW... is it that llvm/utils/TableGen/Record.cpp need an include of > > llvm/Support/DataTypes.h for having the right typedef of int64_t? > > ;-)) > > > > Jeff Cohen wrote: > > > > >OK. I strongly support that sentiment. > > > > > >Paolo, could you send me your procedure for building under Windows? I > > >haven't tried to build anything but System/Win32 so far. > > > > > > > > >On Fri, 24 Sep 2004 07:52:23 -0700 > > >Reid Spencer <reid at x10sys.com> wrote: > > > > > > > > > > > >>I'll wait for the research. We should try, as much as possible, to make > > >>it work with just what the compiler provides and without third party > > >>packages. > > >> > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: Signals.diff Type: application/octet-stream Size: 1489 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040924/fe742ac7/attachment.obj>
Well, I just tried to copy the files generated by configure to Windows for building there. It's a non starter. They are totally dependent on the Unix environment and it would be simpler to start from scratch. The scons approach of generating VC project files is very interesting (but what about the solution file?). Unfortunately, a serious attempt at this would take far more time than I have available right now so I cannot pursue it. On Fri, 24 Sep 2004 17:28:54 +0200 Paolo Invernizzi <arathorn at fastwebnet.it> wrote:> It would be great to avoid STLPort and use plain vanilla VC... as I > told, the biggest difference it's how the hash_map and hash_set are > implemented, but I'm not so strong in C++ for resolving the iussue. > > About the build procedure, it's based on scons, and it's still at a very > preliminary stage... > Right now I'm trying to build TableGen with it, as till now I've always > copied TableGen results from the cygwin build ;-) > Gime me a little more time, as I'm in the middle of this, and then I'll > post it to the list. > > --- > Paolo Invernizzi > > BTW... is it that llvm/utils/TableGen/Record.cpp need an include of > llvm/Support/DataTypes.h for having the right typedef of int64_t? > ;-)) > > Jeff Cohen wrote: > > >OK. I strongly support that sentiment. > > > >Paolo, could you send me your procedure for building under Windows? I > >haven't tried to build anything but System/Win32 so far. > > > > > >On Fri, 24 Sep 2004 07:52:23 -0700 > >Reid Spencer <reid at x10sys.com> wrote: > > > > > > > >>I'll wait for the research. We should try, as much as possible, to make > >>it work with just what the compiler provides and without third party > >>packages. > >> > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
On Sep 25, 2004, at 10:27 PM, Jeff Cohen wrote:> The > scons approach of generating VC project files is very interesting (but > what about the solution file?).Along with the project file it generates also the solution file. The current limitation is that you cannot generate one solution for multiple projects (but you can handle multiple variant in the same project). Usually I create manually an empty solution and manually add all the generated projects to it. You have to do this only the first time. --- Paolo Invernizzi