search for: barrkel

...built it on Cygwin, it looks like I'll have to cobble together a DLL out of the libraries myself. I can't imagine I'm the first to want a pre-packaged DLL containing all the relevant bits, along with DLL exports etc. Has someone else done this work? Thanks, -- Barry -- http://blog.barrkel.com/

...ked). The MSBuild infrastructure isn't used by VS 2005 for C++ projects; rather, VCBuild does the work. I'm not sure about VS 2008. FWIW, I used ProcMon to diagnose file-handling issues I had in my build: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx -- Barry -- http://barrkel.blogspot.com/

...like I'll have to > cobble together a DLL out of the libraries myself. I can't imagine I'm > the first to want a pre-packaged DLL containing all the relevant bits, along > with DLL exports etc. Has someone else done this > work? Thanks, -- Barry -- > http://blog.barrkel.com/ _______________________________________________ LLVM > Developers mailing list > href="mailto:LLVMdev at cs.uiuc.edu">LLVMdev at cs.uiuc.edu > > http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

...08 were > supported, I'd consider using it. The current solution and project files work > less than optimally when auto-upgraded by VS2008. Are you still > working on an LLVM back end for FPC? What integration approach are / were you > using for that? -- Barry -- http://blog.barrkel.com/

I have "hide dot files" on, but I have noticed that while files with a single dot are hidden, files with multiple dots are not: ".foo" - hidden "...foo" - not hidden Is this by design? *nix certainly hide such files by default... -- Barry -- http://barrkel.blogspot.com/

...GW. If Visual Studio 2008 were supported, I'd consider using it. The current solution and project files work less than optimally when auto-upgraded by VS2008. Are you still working on an LLVM back end for FPC? What integration approach are / were you using for that? -- Barry -- http://blog.barrkel.com/

OK, a couple of things aren't parsing here. > When config.h.in is hit in the build of configure the configure > project, > the configure.h file from the win32 directory is copied to main > llvm\Config\Config.h. The script in the sln file is: > There is no "configure.h" file from the win32 directory; there is a config.h, and it's 600 bytes long, compared to the

Hi, There is a discussion thread on llvm-commits list about a possibility of using custom memory allocators for STL to improve the performance and reduce the memory pressure of STL containers, e.g. std::set. I thought that this discussion may be interesting for a wider audience and therefore I re-post the messages on llvm-dev as well. It would be interesting to hear what others think about -

>There's a config.h file in the win32 subdirectory that implies that it's >supposed to be concatenated as part of the build process, but it doesn't >seem like that's happening from within the .sln script--am I missing a >pre-build step someplace? When config.h.in is hit in the build of configure the configure project, the configure.h file from the win32 directory is