search for: scon

...he proper libraries. > > I included also a demo version of the HowToUseJIT Visual studio project > generated by the script. > You can debug the program in the usual way with VS, stepping betweeen > the source code. Keep in mind that the VS project is updated > automatically by scons, so if you want to modify some flags do it via > the script. Hi Paolo, I quickly went over your SConstruct file. So here are a few comments: * It would be nice if it is broken down to smaller files (I see you mention this in the comments). Also a file per tool/library can give us what make...

...d HowToUseJIT.exe among with the proper libraries. I included also a demo version of the HowToUseJIT Visual studio project generated by the script. You can debug the program in the usual way with VS, stepping betweeen the source code. Keep in mind that the VS project is updated automatically by scons, so if you want to modify some flags do it via the script. Enjoy. --- Paolo Invernizzi -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm.zip Type: application/x-zip-compressed Size: 24400 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/l...

...XPJ to generate the initial VS projects for a code base that doesn't > already have VS projects. I also find it nice to be able to see all of > the config options in a flat, human readable file rather than a GUI, > but this is certainly personal preference. We are more likely to adopt scons (via HLVM integration) than XPJ. Scons provides a common build specification for all platforms (Win32, Unix, MacOS, mainframe) and can also generate the Visual Studio files as necessary. This would completely automate the process. As Unix developers modify the Scons build scripts, the win32 direct...

>From: Paolo Invernizzi <arathorn at fastwebnet.it> >Date: Thu, 16 Sep 2004 10:20:39 +0200 > >I'm using scons to generate that files from .in files. I implemented in it >the configure check regarding iterators, hash and so on... >something like: > Hey, you've found the tool that makes it possible to generically reading Makefiles... Cool - The tool I've requested... >scons: Reading...

...interested, > I can steer my work to cover all platforms. We (RapidMind) are very interested. We would very much like to see a unified build system across MSVC/Windows and gcc/Linux/OS X. We have considered contributing such a build system, and if we were to do so would probably base it on SCons (http://www.scons.org/) because we already use SCons extensively. I have a small prototype of this. We're not really partial to a particular implementation though, as long as it allows a unified, scriptable, build environment across the various platforms. SCons has the nice property th...

On Sep 26, 2004, at 12:58 AM, Alkis Evlogimenos wrote: > * It would be nice if it is broken down to smaller files (I see you > mention this in the comments). Also a file per tool/library can give us > what make cannot: cd into a tools subdir and run scons: this will build > the tool and all its dependances. Thats true, splitting it is a must. I simply feel more confortable during early stage of development to keep all compact. But note that you can currently select what target you want to build via the command line. Every builded target can b...

I've been using SCons as the build tool for my frontend application, and I'm getting to the point where it would be useful to create a custom scanner for my generated bitcode files so that SCons can do proper dependency analysis. At the moment, SCons has no way to know which source files a particular bitcode fi...

I don't want to drive this too off topic, but I should be clear that I wasn't suggesting that the LLVM project adopt XPJ as it's official config file format for Visual Studio. I have found it useful to use XPJ to generate the initial VS projects for a code base that doesn't already have VS projects. I also find it nice to be able to see all of the config options in a

...lines). Hunk #3 succeeded at 191 (offset 20 lines). Hunk #4 succeeded at 353 (offset 108 lines). jason$ cd ffmpeg jason$ ./configure --enable-gpl --enable-swscale --enable-postproc -- disable-muxers --disable-encoders --enable-libvorbis --enable-pthreads && make ... jason$ cd ../ jason$ scons scons: Reading SConscript files ... scons: warning: The Options class is deprecated; use the Variables class instead. File "/Users/jason/ffmpeg2theora/SConstruct", line 22, in <module> scons: warning: The BoolOption() function is deprecated; use the BoolVariable() function in...

Stefanus Du Toit <sdt at rapidmind.com> writes: [snip] > We have considered contributing such a build system, and if we were to > do so would probably base it on SCons (http://www.scons.org/) because > we already use SCons extensively. At first, SCons is what I intended too. But then I read about the KDE experience and took the safe route :-) [snip] > Are you intending for your build system to support all the features of > the existing make-based...

On Sun, 2004-09-26 at 12:42, Paolo Invernizzi wrote: > Attached to this email you can find it and a new series of patches > against current CVS, that I hope are pretty safe. Paolo, I applied most of your patches to cvs. I didn't apply the patches for things under lib/Support. I will leave that to Reid (if you can resend those to this list it would be great). Here is the list of the

...(15) : error C2888: 'bool `anonymous-namespace'::X86ATTAsmPrinter::printInstruction(const llvm::MachineInstr *)' : symbol cannot be defined within namespace 'llvm' tablegen_includes\X86GenATTAsmWriter.inc(469) : fatal error C1204: compiler limit : internal structure overflow scons: *** [build_vc71\lib\Target\X86\X86AsmPrinter.obj] Error 2 scons: building terminated because of errors. --- Paolo Invernizzi

On 2008-04-28, at 23:21, Talin wrote: > I've been using SCons as the build tool for my frontend application, > and > I'm getting to the point where it would be useful to create a custom > scanner for my generated bitcode files so that SCons can do proper > dependency analysis. At the moment, SCons has no way to know which > source files...

The scons file that I posted yesterday is broken... I've not taken in account the commit of 2 days ago that modified *iterator.in* and friends. I've updated it and now it works again; inside it you can find comments about what files currently are NOT compiled and why (hint appreciated!) Attached...

[Repost: The mailing list was down yesterday. Sorry if this is a duplicate] I'm evaluating CMake (1) primarily as an alternative build system for Visual Studio users, although it can easily be a replacement for `configure' and hand-made makefiles too, providing a single build system for all platforms. CMake is a tool that takes a project description and configures, generates makefiles,

...rated for Windows, things like supporting pathnames properly and escaping is really tricky (or does CMake do a perfect job here?). Since most developpers won't be able to test their changes to the build system on all platforms, I expect the system to be broken quite often. An approach like scons, which does not rely on legacy tools, seems more robust to me. At least we can expect a similar behavior of the build system on all the supported platforms. I haven't tried scons itself, but my company is happily using the OMake build system http://omake.metaprl.org/index.html OMake has b...

Hi I'm trying to compile HowToUseJIT.cpp, but it seems that iterator definition is missing: --------------------Configuration: HowToUseJIT - Win32 Debug-------------------- Compiling... HowToUseJIT.cpp c:\sfu\usr\local\src\llvm\include\llvm\adt\ilist(41) : fatal error C1083: Cannot open include file: 'llvm/ADT/iterator': No such file or directory Error executing cl.exe. I've

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

...> `anonymous-namespace'::X86ATTAsmPrinter::printInstruction(const > llvm::MachineInstr *)' : symbol cannot be defined within namespace 'llvm' > tablegen_includes\X86GenATTAsmWriter.inc(469) : fatal error C1204: > compiler limit : internal structure overflow > > scons: *** [build_vc71\lib\Target\X86\X86AsmPrinter.obj] Error 2 > scons: building terminated because of errors. > > --- > Paolo Invernizzi > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.u...

...nesday, July 30, 2008 11:18 AM To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Is there room for another build system? Stefanus Du Toit <sdt at rapidmind.com> writes: [snip] > We have considered contributing such a build system, and if we were to > do so would probably base it on SCons (http://www.scons.org/) because > we already use SCons extensively. At first, SCons is what I intended too. But then I read about the KDE experience and took the safe route :-) [snip] > Are you intending for your build system to support all the features of > the existing make-based...