On Sun, 1 Jul 2007, Tanya M. Lattner wrote:> I don't think we should have a docs module. Its much better to allow a > person to check out only llvm and get the appropriate documentation. Same > for hlvm, and whatever project. Its very inconvenient to check out > multiple things just to get llvm and docs.To put it another way, I think the docs for the subproject should follow the subproject.>> 4. /utils/ (or perhaps /tools/) >> I think there's an opportunity for us to put some common tools that are >> used by several modules into a top level module named /utils/. Initially >> this could be a merge of the hlvm and llvm module /utils/ directory >> (excluding things like tblgen which is llvm specific). > > What tools are common? This is another thing someone has to check out.I think that there is common stuff, but we should keep it as minimal as possible. I think that llvm-config should be common, but can't think of anything else that should be. In particular, with a unified llvm-project world, I think checking out llvm-project should give you something like this: mydir/llvm-project/ llvm-config/* README.txt Makefile And probably nothing else. Importantly, the README.txt would talk about how to use the makefile, suggesting common things, like: make checkout PROJECT=llvm-gcc which checks out llvm-gcc and all dependencies. The makefile itself would have no project-specific details in it, it would require all the projects to be self describing about their dependencies. llvm-gcc depends on llvm which depends on llvm-support or something. 'make checkout' would check out the requested project, then recursively check out its dependencies. This would give you a tree like this: mydir/llvm-project/ llvm-config/* llvm/* {lib/utils/tools/include/...} llvm-gcc/* {gcc/fastjar/intl/zlib/...} support/* {lib/include} README.txt Makefile The ability for the makefile to drive an arbitrary build system is pretty important. We already have llvm and llvm-gcc which have totally different build systems. By having the top-level independent of any individual build system, we can independently move things to scons or whatever with little pain (just have a text file in the top-level of each project that says "run this command to build me" "run this command to test me" etc). -Chris -- http://nondot.org/sabre/ http://llvm.org/
On 2007-07-02, at 03:49, Chris Lattner wrote:> I think checking out llvm-project should give you something like this: > > mydir/llvm-project/ > llvm-config/* > README.txt > Makefile > > And probably nothing else. > > Importantly, the README.txt would talk about how to use the > makefile, suggesting common things, like: > > make checkout PROJECT=llvm-gcc > > which checks out llvm-gcc and all dependencies. > […] > 'make checkout' would check out the requested project, then > recursively check out its dependencies.As a possibly less-engineered complement, your end-state could be provided simply by creating folders in Subversion prefabbed with appropriate svn:externals. Make one for each end-project (llvm-gcc, new-cfe, and soforth). It's not nearly so clever, but it might allow initial usage much closer to the 'configure; make; make install' convention. Also, there's only enough info on the command-line there to do a trunk checkout. What about branches and tags? Sorry to harp on these, but my experience with Subversion is that it's important to accommodate them. In one sense, the simplest way to do so is to make the project ignorant of the source control system. That generality is part of the appeal about using one giant trunk for everything. It's also the reason that svn:external is appealing: it puts the source control smarts in the source control system, not the controlled project. — Gordon
On Mon, 2 Jul 2007, Gordon Henriksen wrote:> As a possibly less-engineered complement, your end-state could be > provided simply by creating folders in Subversion prefabbed with > appropriate svn:externals. Make one for each end-project (llvm-gcc, > new-cfe, and soforth). It's not nearly so clever, but it might allow > initial usage much closer to the 'configure; make; make install' > convention.My goal is to make it so you *don't* check out all of the LLVM stuff by default. For example, the webpage has binaries of every release so far. Noone wants to check that stuff out. Likewise, LLVM has several "dead/in-stasis" projects (like llvm-java and llvm-tv) which people don't want to check out unless they are interested in revitalizing them. I don't know enough about svn-externals to know how it handles this.> Also, there's only enough info on the command-line there to do a > trunk checkout. What about branches and tags? Sorry to harp on these, > but my experience with Subversion is that it's important to > accommodate them.Branches are really only important to us for releases. -Chris -- http://nondot.org/sabre/ http://llvm.org/