[LLVMdev] Top Level Stuff

[Reid Spencer]

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