[LLVMdev] An LLVM 1.3 Request

[Reid Spencer]

On Tue, 2004-04-13 at 19:10, Chris Lattner wrote:

> Yes, definitely.  I think the right way to do this is to make it be as
> incremental as possible.  In particular, the biggest benefit will be to
> get llvm/test/Programs into a seperate tarball from the main LLVM tree, as
> it is big and will (hopefully!) keep getting bigger.  There are several
> tasks that can be done incrementally to help out with this:
> 
> 1. Make test/Programs be self contained, including not depending on
>    makefiles in directories above it.
> 2. It should have its own (small) configure script, just like the other
>    projects do.
> 3. It should "act" as if it were in llvm/projects/TestPrograms or
>    something.  Before the files are actually moved, this can be simulated
>    with a symlink.
> 
This is completely opposite the way I work. If I had CVS access, I would
do the whole change in a branch. This would include fixing all
makefiles, moving all files, creating/fixing configure scripts, and
running all regressions to make sure it worked. I would then check in
the branch, merge mainline into it again and re-test. Once I was synched
with mainline and everything checked out, I'd commit again.  The branch
would be verified independently by someone else before being merged back
to mainline.

Trying to do a global change in a piecemeal fashion will just create
pain for more people. For example, how would I supply a patch to
autoconf/configure.ac that removes support for, say --enable-spec2000
and that still lets you configure for testing? Attempting to do this
piecemeal (or "incrementally" as you put it :) will just lead to
confusion for everyone. Trust me, I've been there and done that.

> Once these three are done, it should just be a matter of moving the CVS ,v
> files from llvm/test/Programs into llvm/projects/TestPrograms, and then
> into a seperate CVS module when that works goes well.

I agree that moving the cvs files is a last step, but its also something
that needs to be done incrementally as the solution is built in a
branch.

> 
> I attached a small draft of one vision of a future LLVM directory layout
> to the end of PR257.  Please take a look and add a comment if you think
> that something else would make sense.

Saw it, commented on it.

> 
> > The end goal of this change is to minimize the size of a standard
> > distribution of LLVM and make configuration and building easier.
> 
> This is *clearly* a useful change :)

Especially if you are over dialup or DSL :)

> 
> At this point, sending in patches is probably the easiest thing to do.
> Figuring out how to set up the permissions, deal with the politics of
> giving external access to university machines, and other annoying details
> is just not something that is very appealing to me, and the actual CVS
> work is pretty small.

Unfortunately, I won't be able to do that for this kind of project. The
logistics of trying to keep track of a multitude of patches while at the
same time keeping the build tree clean for other purposes is beyond the
kind of time I have available.  The reality of my work schedule is that
I get very few concentrated periods of time to work on things. The way I
handle this is by creating a branch that is separate from other things
where I can work on a related set of changes.  Other sets of changes are
in other branches.

I'm willing to help, but it has to be efficient with my time too.

Thanks,

Reid.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20040413/22504883/attachment.sig>