llvm dev - Feb 2011 - [LLVMdev] RFC: LLVM Release Documentation Changes

Hi all,

I'm working up some changes in the way LLVM is released. Attached is the
latest HTML file for HowToReleaseLLVM.html. The major change is in how we do
branching and tagging. I want to use a hierarchical version of tags for the
various release candidates and final release. The structure of the tags would be
something like this.

The 2.9 release branch:

	https://llvm.org/svn/llvm-project/llvm/branch/release_29

The 2.9 release candidate 1:

	https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_29/RC1

The 2.9 release candidate 2:

	https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_29/RC2

The 2.9 final release (the one we send out to the public):

	https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_29/Final

Once created, the tags will never change. The branch may change. Though after
the final release the branch shouldn't really change.

Duncan brought up the question of how to release clang. It would be nice to
package clang by itself without all of the LLVM tools. Basically, making it a
standalone package. I have no problem with this (in fact, I think it's a
great idea), but it does mean changing Makefiles and stuff. Any help with this
would be greatly appreciated.

Comments?

-bw

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110225/1eb6c4dd/attachment.html>
-------------- next part --------------

On 25 February 2011 22:46, Bill Wendling <wendling at apple.com>
wrote:
> Duncan brought up the question of how to release clang. It would be nice to
package clang by itself without all of the LLVM tools. Basically, making it a
standalone package. I have no problem with this (in fact, I think it's a
great idea), but it does mean changing Makefiles and stuff. Any help with this
would be greatly appreciated.
Hi Bill,

We were discussing exactly that this week. With Clang inside LLVM's
tree, it's hard for us to create separate (internal) products for
them, so we can build and test them separately (EDG+LLVM against
Clang+LLVM). But I'm not sure we're the most common types of users...

I believe the Debian package for Clang is separate from LLVM, which
makes sense, but that might be hard to produce, given that they're too
tightly coupled... Debian maintainers would know more... ;)

cheers,
--renato

On Fri, Feb 25, 2011 at 2:46 PM, Bill Wendling <wendling at apple.com>
wrote:
> Hi all,
>
> I'm working up some changes in the way LLVM is released. Attached is
the latest HTML file for HowToReleaseLLVM.html. The major change is in how we do
branching and tagging. I want to use a hierarchical version of tags for the
various release candidates and final release. The structure of the tags would be
something like this.
>
> The 2.9 release branch:
>
>        https://llvm.org/svn/llvm-project/llvm/branch/release_29
>
> The 2.9 release candidate 1:
>
>        https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_29/RC1
>
> The 2.9 release candidate 2:
>
>        https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_29/RC2
>
> The 2.9 final release (the one we send out to the public):
>
>        https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_29/Final
>
> Once created, the tags will never change. The branch may change. Though
after the final release the branch shouldn't really change.
This seems like a good improvement to me.
> Duncan brought up the question of how to release clang. It would be nice to
package clang by itself without all of the LLVM tools. Basically, making it a
standalone package. I have no problem with this (in fact, I think it's a
great idea), but it does mean changing Makefiles and stuff. Any help with this
would be greatly appreciated.
While that would be nice, I doubt it makes sense for 2.9. We probably
need the feature work on the Makefiles etc. to happen on TOT first,
before we consider leveraging that in the release process.

 - Daniel
>
> Comments?
>
> -bw
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

On Sat, Feb 26, 2011 at 10:50:23PM +0000, Renato Golin
wrote:
> On 25 February 2011 22:46, Bill Wendling <wendling at apple.com>
wrote:
> > Duncan brought up the question of how to release clang. It would be
nice to package clang by itself without all of the LLVM tools. Basically, making
it a standalone package. I have no problem with this (in fact, I think it's
a great idea), but it does mean changing Makefiles and stuff. Any help with this
would be greatly appreciated.
> 
> Hi Bill,
> 
> We were discussing exactly that this week. With Clang inside LLVM's
> tree, it's hard for us to create separate (internal) products for
> them, so we can build and test them separately (EDG+LLVM against
> Clang+LLVM). But I'm not sure we're the most common types of
users...
> 
> I believe the Debian package for Clang is separate from LLVM, which
> makes sense, but that might be hard to produce, given that they're too
> tightly coupled... Debian maintainers would know more... ;)
We're doing separate builds in the FreeBSD ports collection.  You have
to have the LLVM source try around and we configure against the whole
tree, but we can build against and installed version of llvm with only a
few hacks.  The basic process is:

- extract llvm and clang sources.
cd <llvm-src-root>
./configuire <args>
ln -s ${PREFIX}/include/llvm/Intrinsics.gen <llvm-src-root>/include/llvm
cd utils/unittest/googletest
gmake
cd <llvm-src-root>/tools/clang
gmake
gmake install

The need to build googletest is relatively recent.  Oddly, if you just
install libGoogleTest.a as part of the LLVM package build you get build
errors.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20110301/7fac90a2/attachment.sig>