search for: bjam

...lot of > customization of automake itself, it just can't grok the fact that there > might be multiple ways to compile a c/c++ program producing different > results and requiring different tools. Boost.Build supports this very good. In particular, on my project on work I can run: bjam toolset=gcc bjam toolset=nm bjam toolset=nmm and the first will do a regular build, the third will compile for some embedded processor, and the third will pass the sources via some annotation tool and produce an annotated x86 binary. Besides, "toolset=gcc" can become "tools...

...tomake itself, it just can't grok the fact that there > > might be multiple ways to compile a c/c++ program producing different > > results and requiring different tools. > > Boost.Build supports this very good. In particular, on my project on work I > can run: > > bjam toolset=gcc > bjam toolset=nm > bjam toolset=nmm > > and the first will do a regular build, the third will compile for some > embedded processor, and the third will pass the sources via some annotation > tool and produce an annotated x86 binary. > > Besides, "tool...

...mentation is simple. Look in the html subdirectory to see the generated html as separate files, but it can also generate a single large html file, pdf, man pages, docbook, whatever. The source qbk files and Jamroot is included, but it would be a cinch to have CMake build it instead. If you do: bjam -n html then it will not build it, but it outputs all of the commands and everything it does, which is surprisingly little, so yes, it could be integrated with ease. I ported the first two chapters of the C++ Kaleidoscope tutorial to it. I used the standard boost-style setup, except as an example...

...>>> least, it was intimately tied to the Boost project. That may have >>> changed recently, I don't know. >> >> What of it is too tied to Boost? Once compiled it is completely standalone. > > It's been a while, but IIRC the doxygen integration relied on bjam > somehow, finding the tools perhaps? The BoostBook XML files also > hard-code some assumptions about the project layout, IIRC. > > If building the tool requires Boost.Build that is a pretty heavy burden. None of them rely on bjam, bjam just knows the commands, but as stated you can u...

...easy for a motivated engineer to > generate "clean" Xcode projects for LLVM. Couldn't a similarly motivated engineer work on greatly improving the "clean" Xcode projects for cmake in general? My personal main experience of a similar system is 'boost::build', or bjam, the build system used for the C++ boost libraries. This has slowly grown in scope, and I find completely unusable. It makes simple using boost, or configuring it slightly non-standardly, almost impossible without asking on IRC or mailing lists. bjam is the sole reason I have not submitted signifi...

On Tue, Aug 17, 2010 at 11:09 PM, David A. Greene <greened at obbligato.org> wrote: > Please do.  7z is not supported on Linux. Does not this work? http://packages.debian.org/lenny/p7zip-full Eugene

On Mon, Aug 9, 2010 at 8:51 PM, Chris Lattner <clattner at apple.com> wrote: > > On Aug 8, 2010, at 11:29 PM, Michael Spencer wrote: >> >> What Do You Think? >> ------------------ >> >> I realize that changing the documentation format is non-trivial, but I believe >> that the benefits are worth the effort. If we go forward with this I will finish

On Aug 18, 2010, at 4:01 PM, David A. Greene wrote: > And the fact that Boostbook knows how to import Doxygen XML output is a > killer feature. Having a hardcopy of the Doxygen reference can be > really useful. > > I agree with Chris that at the moment, BoostBook/QuickBook is too hard > to set up. I'm certainly not about to use bcp magic and litter my > workspace with

On Fri, Oct 28, 2011 at 9:56 AM, Óscar Fuentes <ofv at wanadoo.es> wrote: > Reid Kleckner <reid.kleckner at gmail.com> writes: > >> While eliminating duplication is one of the goals I see in this build system >> change, I think the more important ones are a) simplifying the build files >> and b) making the build faster. > > The "build files" are

...parate that from Boost 'would' be difficult, except >> there exists a nice little Boost tool call "bcp". What bcp can do is > > I actually meant "Boost.Build" here. Sorry for creating the confusion. > QuickBook using Spirit is fine. Actually Boost.Build/bjam does not depend on boost at all, not even the source code as it is pure C, not even C++, to allow for the lowest common denominator (although there is talk of a Boost.Build2 being made in Python), and running it does not involve even needing Boost installed, just a Jamroot in your projects director...

OvermindDL1 <overminddl1 at gmail.com> writes: > On Tue, Aug 17, 2010 at 5:25 PM, Chris Lattner <clattner at apple.com> wrote: >> On Aug 17, 2010, at 3:42 PM, OvermindDL1 wrote: >> >>> >>> On Tue, Aug 17, 2010 at 4:09 PM, David A. Greene <greened at obbligato.org> wrote: >>>> OvermindDL1 <overminddl1 at gmail.com> writes:

...l as separate >>> files, but it can also generate a single large html file, pdf, man >>> pages, docbook, whatever. >>> >>> The source qbk files and Jamroot is included, but it would be a cinch >>> to have CMake build it instead.  If you do: >>>  bjam -n html >>> then it will not build it, but it outputs all of the commands and >>> everything it does, which is surprisingly little, so yes, it could be >>> integrated with ease. >>> >>> I ported the first two chapters of the C++ Kaleidoscope tutorial to...

I'm re-thinking my penchant for automake. automake is great for many standard applications that just need to get portable makefiles up and running quickly. However, it turns out that LLVM is "different enough" from a standard application that automake might not be the best choice. Here's some of the problems I've run into: 1. There's no way to tell automake to build

I tried building boost 1.45 release with clang 2.9 following instructions on http://blog.llvm.org/2010/05/clang-builds-boost.html but got the following result: $ clang++ --version clang version 2.9 (trunk 123420) Target: x86_64-apple-darwin10 Thread model: posix $ ./bjam toolset=clang Building the Boost C++ Libraries. Performing configuration checks - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - ../config//has_gcc_visibilit...

On Mon, Aug 9, 2010 at 11:29 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > You are right that BoostBook is targeted directly for large C++ > projects, and I seriously considered BoostBook for this project, but > ran into a few road blocks. > > * It's tightly integrated into boost and makes quite a few assumptions > about that. What assumptions is that? On

One more update. The Makefile.am for analyze was wrong. It wasn't linking in the some of the passes. The new size is 56951088 which is in line with the other executables. Also, I have now completed a run of projects/llvm-test/MultiSource with the tools generated by automake. The only errors were for: TEST (llc) 'sgefa' FAILED! TEST (jit) 'sgefa' FAILED! TEST (jit)

> I studied some a few years ago and concluded that it > was not worth the trouble. "Boost C++ Libraries" uses perforce jam ( in their case it's modified jam: bjam http://www.boost.org/doc/tools/jam/index.html ). Jam works well with massive structures of autonomous projects that constitute a collection of libraries and must be built on multiple platforms and with different tools. It may be a project on its own to create a robust build system of jamfiles, bu...

...stem like cmake, while lessening the load of the LLVM developers, increases the load on users of LLVM. I'm building a piece of software and I have to deal with each external dependency using it's own favourite build system - the end result is that to build my software I have to use SCons, bjam, cmake, Visual Studio _and_ nmake. In my opinion the best solution is if the software comes with project files/makefiles that are 'native' to the platform you're building on and doesn't require any extra software to be installed before you can build. I've had good results wi...

On Thu, 24 Jun 2004, Vladimir Prus wrote: > I've just had some fun, because I wanted to override > FunctionPass::addAnalysisUsage, but forgot "const" after the method name -- > so instead of overriding I've just created a new unrelated method. Ya know, I think that everyone has done that at least once (myself included)... on THAT VERY METHOD. grr :) I definitely

On Sunday 18 May 2008, Óscar Fuentes wrote: > Chris Lattner <sabre at nondot.org> writes: > > [snip] > > > Others have suggested alternative build systems before like cmake. > > Apparently cmake can autogenerate VC++ and Xcode project files from > > the same thing that it builds from on unix systems. > > cmake creating VC++ project files does not appeal