search for: jamfil

I too have done some work on an alternative build system for llvm. It is based on boost.build. Of course, it's quite a large project and I'm not ready to contribute the work yet. Ideally I was hoping to replace all of makefile functionality with jamfiles. Boost.build is attractive because support for new compilers/tools comes with new releases of boost.build and need not be added manually by llvm developers/users. Since you're working on a competing build system, I'm no longer sure I want to spend time developing my build system. It wou...

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

Hi there! I was wondering what the general opinion on autotoolizing xen is? I am volunteering to do so, if there is interest in updating the build system to use autoconf, automake and/or libtool. Is one configure script for all of xen enough or do you want to be able to configure all/some tools separately? I know that Anthony is no fan of libtool... are there more reservations about some

...ed 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, but once it's done, it's very easy to maintain (which can be said about any well-designed system :-)

...nts above yet. > 4. There's no way to avoid listing all the sources for every library > (I've tried several alternatives with no good results). Easy, I've already have a half-working setup (only the targets I use are converted), and, for example, lib/Analysis/DataStructure/Jamfile has nothing but: llvm-lib datastructure ; > 5. There's no way to install bytecode libraries somewhere separately > from other libraries. Should be possible. > 6. Creating a distribution tarball would require additional Makefile.am > files to be inserted in all the directori...

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

...ere's no way to avoid listing all the sources for every library > > (I've tried several alternatives with no good results). > > Easy, I've already have a half-working setup (only the targets I use are > converted), and, for example, > > lib/Analysis/DataStructure/Jamfile > > has nothing but: > > llvm-lib datastructure ; > > > 5. There's no way to install bytecode libraries somewhere separately > > from other libraries. > > Should be possible. > > > 6. Creating a distribution tarball would require additional Makefile...

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)