Top Level Stuff

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Top Level Stuff

Reid Spencer-2
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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Vikram S. Adve
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Reid Spencer-2
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
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Tanya Lattner-2
In reply to this post by Reid Spencer-2

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

> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Reid Spencer-2
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Tanya Lattner-2

>>> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Chris Lattner
In reply to this post by Reid Spencer-2
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
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Chris Lattner
In reply to this post by Tanya Lattner-2
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Gordon Henriksen-3
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Gordon Henriksen-3
On 2007-07-02, at 13:56, Chris Lattner wrote:

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.

Right.

I don't know enough about svn-externals to know how it handles this.

It simply embeds checkout commands into the repository. So this directory structure is frequently useful:

   ./
     llvm-gcc/   [from ${svn}/llvm-gcc/trunk]
     llvm/   [from ${svn}/llvm/trunk]
     llvm-config/   [from ${svn}/llvm-config/trunk]
     Makefile   [from ${svn}/utils/trunk/Makefile]

it can be created in the repository, making the checkout process a simple, transparent 'svn co'. This is entirely complementary to your idea.

— Gordon


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Chris Lattner
On Mon, 2 Jul 2007, Gordon Henriksen wrote:

>>  I don't know enough about svn-externals to know how it handles this.
>
> It simply embeds checkout commands into the repository. So this directory
> structure is frequently useful:
>
>     ./
>       llvm-gcc/   [from ${svn}/llvm-gcc/trunk]
>       llvm/   [from ${svn}/llvm/trunk]
>       llvm-config/   [from ${svn}/llvm-config/trunk]
>       Makefile   [from ${svn}/utils/trunk/Makefile]
>
> it can be created in the repository, making the checkout process a simple,
> transparent 'svn co'. This is entirely complementary to your idea.

Yes, but that checks everything out, which is badness.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Reid Spencer-2
On Mon, 2007-07-02 at 14:33 -0700, Chris Lattner wrote:

> On Mon, 2 Jul 2007, Gordon Henriksen wrote:
> >>  I don't know enough about svn-externals to know how it handles this.
> >
> > It simply embeds checkout commands into the repository. So this directory
> > structure is frequently useful:
> >
> >     ./
> >       llvm-gcc/   [from ${svn}/llvm-gcc/trunk]
> >       llvm/   [from ${svn}/llvm/trunk]
> >       llvm-config/   [from ${svn}/llvm-config/trunk]
> >       Makefile   [from ${svn}/utils/trunk/Makefile]
> >
> > it can be created in the repository, making the checkout process a simple,
> > transparent 'svn co'. This is entirely complementary to your idea.
>
> Yes, but that checks everything out, which is badness.

Not really. He didn't define "./". If "./" is:
http://llvm.org/svn/llvm-project/everything then I don't see a problem
with it.

Reid.

>
> -Chris
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Chris Lattner
On Mon, 2 Jul 2007, Reid Spencer wrote:
>>> it can be created in the repository, making the checkout process a simple,
>>> transparent 'svn co'. This is entirely complementary to your idea.
>>
>> Yes, but that checks everything out, which is badness.
>
> Not really. He didn't define "./". If "./" is:
> http://llvm.org/svn/llvm-project/everything then I don't see a problem
> with it.

Ok, if it doesn't cause everything to be checked out, I have no problem
with it.  My svn-fu is weak, if it can work with externals, I'm fine with
it! :)

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Reid Spencer-2
On Mon, 2007-07-02 at 18:44 -0700, Chris Lattner wrote:

> On Mon, 2 Jul 2007, Reid Spencer wrote:
> >>> it can be created in the repository, making the checkout process a simple,
> >>> transparent 'svn co'. This is entirely complementary to your idea.
> >>
> >> Yes, but that checks everything out, which is badness.
> >
> > Not really. He didn't define "./". If "./" is:
> > http://llvm.org/svn/llvm-project/everything then I don't see a problem
> > with it.
>
> Ok, if it doesn't cause everything to be checked out, I have no problem
> with it.

I think you missed the point. It *does* cause everything to be checked
out, but because its in a directory named "everything" you only get that
if you specifically asked for it. This is true of all the other
approaches as well, including putting the t/t/b at the top level. Its
just a matter of what URL you use to check out. For example:

1. Checkout just llvm: svn co
http://llvm.org/svn/llvm-project/llvm/trunk llvm
2. Checkout everything: svn co
http://llvm.org/svn/llvm-project/everything

>  My svn-fu is weak, if it can work with externals, I'm fine with
> it! :)

The summary of this thread is that:

a) doing /trunk/{module}/... is not advised
b) we can use externals to simulate an "everything" dir. That is, we
create
  /everything which has subdirs like llvm, hlvm, test-suite, java,
stacker, etc. which
  have external links to all the /{module}/trunk dirs but named
{module}.

This gives us the best of both worlds.
 
Reid.
>
> -Chris
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Gordon Henriksen-3
In reply to this post by Chris Lattner
On 2007-07-02, at 21:44, Chris Lattner wrote:

On Mon, 2 Jul 2007, Reid Spencer wrote:

it can be created in the repository, making the checkout process a simple, transparent 'svn co'. This is entirely complementary to your idea.

Yes, but that checks everything out, which is badness.

Not really. He didn't define "./". If "./" is: http://llvm.org/svn/llvm-project/everything then I don't see a problem with it.

Ok, if it doesn't cause everything to be checked out, I have no problem with it.  My svn-fu is weak, if it can work with externals, I'm fine with it! :)

I'm not suggesting an "everything" folder, but a "just what I need" folder. One could imagine finding these folders (and possibly more) somewhere in svn:

    gcc/
      Makefile
      llvm-gcc/  [svn:external]
      llvm/  [svn:external]
      llvm-config/  [svn:external]
    ncfe/
      Makefile
      llvm-ncfe/  [svn:external]
      llvm/  [svn:external]
      llvm-config/  [svn:external]

Note that llvm-tv and the web site are appropriately excluded.

This could save new developers from needing to do anything but 'svn checkout; configure; make', which could be pretty cool. Assuming Chris' original idea, those with advanced LLVM-fu can still mix and match projects by checking them out manually; the prefabbed svn:external's are just a shortcut.

— Gordon


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Top Level Stuff

Chris Lattner
On Mon, 2 Jul 2007, Gordon Henriksen wrote:

>>  Ok, if it doesn't cause everything to be checked out, I have no problem
>>  with it.  My svn-fu is weak, if it can work with externals, I'm fine with
>>  it! :)
>
> I'm not suggesting an "everything" folder, but a "just what I need" folder.
> One could imagine finding these folders (and possibly more) somewhere in svn:
>
>      gcc/
>        Makefile
>        llvm-gcc/  [svn:external]
>        llvm/  [svn:external]
>        llvm-config/  [svn:external]
>      ncfe/
>        Makefile
>        llvm-ncfe/  [svn:external]
>        llvm/  [svn:external]
>        llvm-config/  [svn:external]
>
> Note that llvm-tv and the web site are appropriately excluded.
>
> This could save new developers from needing to do anything but 'svn checkout;
> configure; make', which could be pretty cool. Assuming Chris' original idea,
> those with advanced LLVM-fu can still mix and match projects by checking them
> out manually; the prefabbed svn:external's are just a shortcut.

Unfortunately, this does not compose well.  How do I check out the
components required to build llvm-gcc and the ncfe?  Should we have a
project for every permutation?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev