All, The current SVN repository has several modules at the top level (llvm, test-suite, java, stacker, etc.). The modules contain the software that makes up the LLVM Project. However, there is nothing at the top level that explains any of this. So, I am considering doing the following at the top level of the repository (i.e. in http://llvm.org/svn/llvm-project): 1. /README.html Just a short README file in HTML format so that people browsing into the repository can get the lay of the land. This would indicate what the LLVM Project is, what its modules are, where you can find the main website, documentation for each module, etc. 2. /website/ I think the LLVM web site (hosted at http://llvm.org/) should be a subversion module named website. It should not contain the releases (huge files) and should be converted from the original llvm-www CVS module. Additionally, we should set httpd up so that it rewrites any / request to /svn/llvm-project/website. This will allow subversion to auto-update the web site without us having to do a checkout 3. /docs/ Right now the /docs/ url is mapped to /svn/llvm-project/llvm/trunk/docs/ which is okay temporarily, but I'd like to see /docs/ become a subversion module that provides documentation for the project at the meta-level. When llvm-gcc, hlvm and the new C front end all hit the repository there will be a need for some documentation about things that are common across all modules and about the project as a whole. Right now these are handled either by the web site or by the llvm module. 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). 4. "projects" I don't think its appropriate for the llvm/trunk/projects directory to be the place where a "project" is checked out. In fact, I'm not sure the notion of "project" even makes sense any more. I would prefer that we just have a set of modules at the top level and those modules have some inter-dependencies. For example, you should be able to just check out the "test-suite" module at the top level and run it. I think the primary motivation for having it in the llvm/projects directory was so that such projects could auto-configure when LLVM was configured. For newcomers this is unusual and for llvm developers its a maintenance burden. If a project depends on another project, it should just use the normal configure mechanism (e.g. --with-llvm=/path/to/llvm). We could provide some tools in /utils/ to make this easier. Furthermore, not having to support "projects" in the makefile system will make the makefiles much easier to understand and will make the conversion to scons easier. Your thoughts? Reid.
I just have a couple of comments on this: 1. Minor issue: I think the README should be in text format (or text and HTML) so that someone checking it out on the command line can read it easily. 2. If the projects directory goes away, we should provide a different mechanism for someone starting a new project based on LLVM to use as a template. This could include, minimally, a Makefile and a README, but could also include other features (which I think do not exist now) such as test templates, documentation, etc. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.org On Jun 30, 2007, at 5:53 PM, Reid Spencer wrote:> All, > > The current SVN repository has several modules at the top level (llvm, > test-suite, java, stacker, etc.). The modules contain the software > that > makes up the LLVM Project. However, there is nothing at the top level > that explains any of this. So, I am considering doing the following at > the top level of the repository (i.e. in > http://llvm.org/svn/llvm-project): > > 1. /README.html > Just a short README file in HTML format so that people browsing > into the > repository can get the lay of the land. This would indicate what the > LLVM Project is, what its modules are, where you can find the main > website, documentation for each module, etc. > > 2. /website/ > I think the LLVM web site (hosted at http://llvm.org/) should be a > subversion module named website. It should not contain the releases > (huge files) and should be converted from the original llvm-www CVS > module. Additionally, we should set httpd up so that it rewrites any / > request to /svn/llvm-project/website. This will allow subversion to > auto-update the web site without us having to do a checkout > > 3. /docs/ > Right now the /docs/ url is mapped to /svn/llvm-project/llvm/trunk/ > docs/ > which is okay temporarily, but I'd like to see /docs/ become a > subversion module that provides documentation for the project at the > meta-level. When llvm-gcc, hlvm and the new C front end all hit the > repository there will be a need for some documentation about things > that > are common across all modules and about the project as a whole. Right > now these are handled either by the web site or by the llvm module. > > 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). > > 4. "projects" > I don't think its appropriate for the llvm/trunk/projects directory to > be the place where a "project" is checked out. In fact, I'm not > sure the > notion of "project" even makes sense any more. I would prefer that we > just have a set of modules at the top level and those modules have > some > inter-dependencies. For example, you should be able to just check out > the "test-suite" module at the top level and run it. I think the > primary > motivation for having it in the llvm/projects directory was so that > such > projects could auto-configure when LLVM was configured. For newcomers > this is unusual and for llvm developers its a maintenance burden. If a > project depends on another project, it should just use the normal > configure mechanism (e.g. --with-llvm=/path/to/llvm). We could provide > some tools in /utils/ to make this easier. Furthermore, not having to > support "projects" in the makefile system will make the makefiles much > easier to understand and will make the conversion to scons easier. > > Your thoughts? > > Reid. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Sat, 2007-06-30 at 18:37 -0500, Vikram S. Adve wrote:> I just have a couple of comments on this: > > 1. Minor issue: I think the README should be in text format (or text > and HTML) so that someone checking it out on the command line can > read it easily.Okay, good point :)> > 2. If the projects directory goes away, we should provide a different > mechanism for someone starting a new project based on LLVM to use as > a template. This could include, minimally, a Makefile and a README, > but could also include other features (which I think do not exist > now) such as test templates, documentation, etc.Yes, we're not trying to discourage people from their own projects, just trying not to force them to place it at /llvm/trunk/projects ! I would rather provide some utilities in, say, /utils/mkproject (a shell script) that creates a new directory that is set up to use llvm (e.g. the configure script knows about --with-llvm= option). Reid.> > --Vikram > http://www.cs.uiuc.edu/~vadve > http://llvm.org > > > On Jun 30, 2007, at 5:53 PM, Reid Spencer wrote: > > > All, > > > > The current SVN repository has several modules at the top level (llvm, > > test-suite, java, stacker, etc.). The modules contain the software > > that > > makes up the LLVM Project. However, there is nothing at the top level > > that explains any of this. So, I am considering doing the following at > > the top level of the repository (i.e. in > > http://llvm.org/svn/llvm-project): > > > > 1. /README.html > > Just a short README file in HTML format so that people browsing > > into the > > repository can get the lay of the land. This would indicate what the > > LLVM Project is, what its modules are, where you can find the main > > website, documentation for each module, etc. > > > > 2. /website/ > > I think the LLVM web site (hosted at http://llvm.org/) should be a > > subversion module named website. It should not contain the releases > > (huge files) and should be converted from the original llvm-www CVS > > module. Additionally, we should set httpd up so that it rewrites any / > > request to /svn/llvm-project/website. This will allow subversion to > > auto-update the web site without us having to do a checkout > > > > 3. /docs/ > > Right now the /docs/ url is mapped to /svn/llvm-project/llvm/trunk/ > > docs/ > > which is okay temporarily, but I'd like to see /docs/ become a > > subversion module that provides documentation for the project at the > > meta-level. When llvm-gcc, hlvm and the new C front end all hit the > > repository there will be a need for some documentation about things > > that > > are common across all modules and about the project as a whole. Right > > now these are handled either by the web site or by the llvm module. > > > > 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). > > > > 4. "projects" > > I don't think its appropriate for the llvm/trunk/projects directory to > > be the place where a "project" is checked out. In fact, I'm not > > sure the > > notion of "project" even makes sense any more. I would prefer that we > > just have a set of modules at the top level and those modules have > > some > > inter-dependencies. For example, you should be able to just check out > > the "test-suite" module at the top level and run it. I think the > > primary > > motivation for having it in the llvm/projects directory was so that > > such > > projects could auto-configure when LLVM was configured. For newcomers > > this is unusual and for llvm developers its a maintenance burden. If a > > project depends on another project, it should just use the normal > > configure mechanism (e.g. --with-llvm=/path/to/llvm). We could provide > > some tools in /utils/ to make this easier. Furthermore, not having to > > support "projects" in the makefile system will make the makefiles much > > easier to understand and will make the conversion to scons easier. > > > > Your thoughts? > > > > Reid. > > > > _______________________________________________ > > LLVM Developers mailing list > > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> The current SVN repository has several modules at the top level (llvm, > test-suite, java, stacker, etc.). The modules contain the software that > makes up the LLVM Project. However, there is nothing at the top level > that explains any of this. So, I am considering doing the following at > the top level of the repository (i.e. in > http://llvm.org/svn/llvm-project): > > 1. /README.html > Just a short README file in HTML format so that people browsing into the > repository can get the lay of the land. This would indicate what the > LLVM Project is, what its modules are, where you can find the main > website, documentation for each module, etc.This should probably be txt.> 2. /website/ > I think the LLVM web site (hosted at http://llvm.org/) should be a > subversion module named website. It should not contain the releases > (huge files) and should be converted from the original llvm-www CVS > module. Additionally, we should set httpd up so that it rewrites any / > request to /svn/llvm-project/website. This will allow subversion to > auto-update the web site without us having to do a checkoutI don't think this is a good idea. I think it should be labeled llvm-website because it is more clear what website a person has checked out.> 3. /docs/ > Right now the /docs/ url is mapped to /svn/llvm-project/llvm/trunk/docs/ > which is okay temporarily, but I'd like to see /docs/ become a > subversion module that provides documentation for the project at the > meta-level. When llvm-gcc, hlvm and the new C front end all hit the > repository there will be a need for some documentation about things that > are common across all modules and about the project as a whole. Right > now these are handled either by the web site or by the llvm module.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.> 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.> 4. "projects" > I don't think its appropriate for the llvm/trunk/projects directory to > be the place where a "project" is checked out. In fact, I'm not sure the > notion of "project" even makes sense any more. I would prefer that we > just have a set of modules at the top level and those modules have some > inter-dependencies. For example, you should be able to just check out > the "test-suite" module at the top level and run it. I think the primary > motivation for having it in the llvm/projects directory was so that such > projects could auto-configure when LLVM was configured. For newcomers > this is unusual and for llvm developers its a maintenance burden. If a > project depends on another project, it should just use the normal > configure mechanism (e.g. --with-llvm=/path/to/llvm). We could provide > some tools in /utils/ to make this easier. Furthermore, not having to > support "projects" in the makefile system will make the makefiles much > easier to understand and will make the conversion to scons easier.This seems fine as long as its really easy to configure things like llvm-test. If its more difficult then its now, then its not worth it. -Tanya
Hi Tanya, On Sun, 2007-07-01 at 19:38 -0700, Tanya M. Lattner wrote:> > The current SVN repository has several modules at the top level (llvm, > > test-suite, java, stacker, etc.). The modules contain the software that > > makes up the LLVM Project. However, there is nothing at the top level > > that explains any of this. So, I am considering doing the following at > > the top level of the repository (i.e. in > > http://llvm.org/svn/llvm-project): > > > > 1. /README.html > > Just a short README file in HTML format so that people browsing into the > > repository can get the lay of the land. This would indicate what the > > LLVM Project is, what its modules are, where you can find the main > > website, documentation for each module, etc. > > This should probably be txt.Already done. For some reason the .html version isn't recognized by the web server as an HTML and is passed through as plain text, which doesn't help much. So, there's a README.txt at the top level now.> > > 2. /website/ > > I think the LLVM web site (hosted at http://llvm.org/) should be a > > subversion module named website. It should not contain the releases > > (huge files) and should be converted from the original llvm-www CVS > > module. Additionally, we should set httpd up so that it rewrites any / > > request to /svn/llvm-project/website. This will allow subversion to > > auto-update the web site without us having to do a checkout > > I don't think this is a good idea. I think it should be labeled > llvm-website because it is more clear what website a person has checked > out.Perhaps. I figure that /svn/llvm-project/website is pretty clear. If you use /svn/llvm-project/llvm-website it is somewhat redundant. Furthermore, llvm-website could get confused with the llvm sub-project which this website is not intended to be. Its intended to be the master website for all the related projects. We'd start with the content on http://llvm.org/ but migrate it to being at a higher level to represent all the sub-projects (as Chris has wanted to do for some time now). There's no rush on this.> > > 3. /docs/ > > Right now the /docs/ url is mapped to /svn/llvm-project/llvm/trunk/docs/ > > which is okay temporarily, but I'd like to see /docs/ become a > > subversion module that provides documentation for the project at the > > meta-level. When llvm-gcc, hlvm and the new C front end all hit the > > repository there will be a need for some documentation about things that > > are common across all modules and about the project as a whole. Right > > now these are handled either by the web site or by the llvm module. > > 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.Almost everyone who reads the documentation does so online by going to http://llvm.org/docs/. I expect that mode of operation to continue. It seems highly inconvenient to require people to check out the documentation in order to read it. Currently, http://llvm.org/docs/ is mapped to http://llvm.org/svn/llvm-project/llvm/trunk/docs, This doesn't make sense to me except as a temporary situation. As the projects get merged together we will need some kind of (probably small and short) /docs/ at the top level that will describe the entire set of sub-projects and provide hyperlinks to them. With the current situation, there's no way to see the HLVM documentation except via a rather verbose URL: http://llvm.org/svn/llvm-project/hlvm/trunk/docs/. I'd just like to make the documentation for each sub-project easier to find when browsing.> > > 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?Things like, especially, the makefile system and common configure stuff. Other tools like mkpatch and a few others would also find some common utility.> This is another thing someone has to check out.I don't see this as being particularly troublesome, especially if we rearrange the top level as I suggested in my prior email.> > > 4. "projects" > > I don't think its appropriate for the llvm/trunk/projects directory to > > be the place where a "project" is checked out. In fact, I'm not sure the > > notion of "project" even makes sense any more. I would prefer that we > > just have a set of modules at the top level and those modules have some > > inter-dependencies. For example, you should be able to just check out > > the "test-suite" module at the top level and run it. I think the primary > > motivation for having it in the llvm/projects directory was so that such > > projects could auto-configure when LLVM was configured. For newcomers > > this is unusual and for llvm developers its a maintenance burden. If a > > project depends on another project, it should just use the normal > > configure mechanism (e.g. --with-llvm=/path/to/llvm). We could provide > > some tools in /utils/ to make this easier. Furthermore, not having to > > support "projects" in the makefile system will make the makefiles much > > easier to understand and will make the conversion to scons easier. > > This seems fine as long as its really easy to configure things like > llvm-test. If its more difficult then its now, then its not worth it.It should be about as easy and less confusing.> > -Tanya > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
On Sat, 30 Jun 2007, Reid Spencer wrote:> The current SVN repository has several modules at the top level (llvm, > test-suite, java, stacker, etc.). The modules contain the software that > makes up the LLVM Project. However, there is nothing at the top level > that explains any of this. So, I am considering doing the following at > the top level of the repository (i.e. in > http://llvm.org/svn/llvm-project):I like the spirit of this, if not the implementation. In particular, I don't think that there should be a "projects" subdir, I think that everything (the current llvm repo in particular) should be top-level dirs under the llvm-project root. However, I explicitly *don't* think this should be the svn layout. Each separate subproject should be its own svn world. We should just encourage this "unified" filesystem layout by making it the easiest and most convenient thing for our users to do. -Chris> 1. /README.html > Just a short README file in HTML format so that people browsing into the > repository can get the lay of the land. This would indicate what the > LLVM Project is, what its modules are, where you can find the main > website, documentation for each module, etc. > > 2. /website/ > I think the LLVM web site (hosted at http://llvm.org/) should be a > subversion module named website. It should not contain the releases > (huge files) and should be converted from the original llvm-www CVS > module. Additionally, we should set httpd up so that it rewrites any / > request to /svn/llvm-project/website. This will allow subversion to > auto-update the web site without us having to do a checkout > > 3. /docs/ > Right now the /docs/ url is mapped to /svn/llvm-project/llvm/trunk/docs/ > which is okay temporarily, but I'd like to see /docs/ become a > subversion module that provides documentation for the project at the > meta-level. When llvm-gcc, hlvm and the new C front end all hit the > repository there will be a need for some documentation about things that > are common across all modules and about the project as a whole. Right > now these are handled either by the web site or by the llvm module. > > 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). > > 4. "projects" > I don't think its appropriate for the llvm/trunk/projects directory to > be the place where a "project" is checked out. In fact, I'm not sure the > notion of "project" even makes sense any more. I would prefer that we > just have a set of modules at the top level and those modules have some > inter-dependencies. For example, you should be able to just check out > the "test-suite" module at the top level and run it. I think the primary > motivation for having it in the llvm/projects directory was so that such > projects could auto-configure when LLVM was configured. For newcomers > this is unusual and for llvm developers its a maintenance burden. If a > project depends on another project, it should just use the normal > configure mechanism (e.g. --with-llvm=/path/to/llvm). We could provide > some tools in /utils/ to make this easier. Furthermore, not having to > support "projects" in the makefile system will make the makefiles much > easier to understand and will make the conversion to scons easier. > > Your thoughts? > > Reid. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://nondot.org/sabre/ http://llvm.org/
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/