[LLVMdev] Top Level Stuff

[Tanya M. Lattner]

>>> 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).

If you check it out, you don't get that full path. Secondly, the LLVM 
website is for LLVM. There may happen to be subprojects that might want 
info about them on the website, but that doesn't change the fact thats its 
the main LLVM website. So it should be named llvm-website.

>>> 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.

Thats not totally true. Most people (those who are working with TOT) read 
the docs online, but not everyone. I can think of two examples: people 
working offline and people who are working with older releases. I don't 
think you can just assume everyone reads the website.

We can fix url issues with apache rewrite rules just a we do now. However, 
if someone checks out LLVM, they should expect to also get the docs. It 
really doesn't make any sense to require someone to check out another 
module and then get a bunch of random documentation that doesn't 
necessarily apply directly to what they checked out.

Subprojects are just that. They should have their own documentation and 
live in their own module. People who own those subprojects should be 
responsible for keeping their docs up to date. I don't think we should 
clutter LLVM docs with a bunch of subproject documentation that may get 
out of date for whatever reason. We have enough trouble keeping LLVM docs 
up to date.

>>> 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.

Ok, but none of those things live in utils now (except mkpatch). So would 
someone be required to check this out to configure LLVM? If its just stuff 
so they can make a new project, then thats fine. I don't think we should 
be moving everything out of llvm/utils though. Only the bare min. You want 
to make it VERY easy for someone to get started with LLVM and requiring 
them to check out this and that, really starts to be a pain.

>> 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.

If we rearrange like you want, then it seems like suddenly its you check 
out everything or you are forced to check out each submodule (if you dont 
want everything in trunk). Is that correct? If so, that doesn't seem like 
a very elegant solution. What we have right now is much more straight 
forward.

-Tanya