LLVM 3.7 release plans

Project Infrastructure LLVM Dev List Archives
1

Hello everyone,

There is still some time to go, but I would like to share my
preliminary plan for 3.7.

The idea is to keep us on the 6-month release cycle, which means:

- Branch for 3.7 on 14 July 2015
- Release 3.7 end of August (absolutely no later than 4 September)

I also have a few things I'd like to try this time:

- Announce the first release candidate on llvm-announce to encourage
more early testing. Last time many issues were raised late in the
process. I'm sure that will happen this time too, but announcing the
RC to a wider audience might help mitigate some of that.

- Using CMake for the release binaries. I think I promised we'd do
this for 3.7. I haven't actually started looking at this yet, but I'm
still optimistic.

- Provide a tarball with the docs and doxygen as part of the release.

- PGP signatures on pre-built binaries: the person who builds the
binary should sign it (unless you think this is too involved).

- Not including Dragonegg in the release; it seems pretty unmaintaned by now.

Please let me know what you think!

Cheers,
Hans

2

Hello everyone,

There is still some time to go, but I would like to share my
preliminary plan for 3.7.

The idea is to keep us on the 6-month release cycle, which means:

  • Branch for 3.7 on 14 July 2015
  • Release 3.7 end of August (absolutely no later than 4 September)

I also have a few things I’d like to try this time:

  • Announce the first release candidate on llvm-announce to encourage
    more early testing. Last time many issues were raised late in the
    process. I’m sure that will happen this time too, but announcing the
    RC to a wider audience might help mitigate some of that.

  • Using CMake for the release binaries. I think I promised we’d do
    this for 3.7. I haven’t actually started looking at this yet, but I’m
    still optimistic.

I’ve been very slowly chipping away at issues that are holding back Debian packaging from using CMake. I’ve got a question about a small break in compatibility with autotools.

Over at http://reviews.llvm.org/D10562, I have a patch up for review that adds a clang(1) man page to the Sphinx docs in clang/docs, and adds a CMake target for it. At the moment there is Makefile under clang/docs/tools that builds a man page using pod2man, but no CMake target.

I’d like to remove cmake/docs/tools/Makefile, clang.pod and associated files. Packagers would need to build the man page using Sphinx, which is what is done for LLVM tools (llc, lli, etc.) at the moment. Even if using autotools, the man page can be built by invoking Makefile.sphinx directly. Does anyone object to this change happening before branching for 3.7?

Cheers,
Andrew

3

- Branch for 3.7 on 14 July 2015
- Release 3.7 end of August (absolutely no later than 4 September)

Sounds like a plan!

- Announce the first release candidate on llvm-announce to encourage
more early testing. Last time many issues were raised late in the
process. I'm sure that will happen this time too, but announcing the
RC to a wider audience might help mitigate some of that.

I'm not sure llvm-announce is a larger audience, but won't hurt to CC it.

- Using CMake for the release binaries. I think I promised we'd do
this for 3.7. I haven't actually started looking at this yet, but I'm
still optimistic.

I'm absolutely in agreement with this. Most of us already use CMake
for development, a lot of the buildbots are based on it and I think we
all agree that autoconf is deprecated. Makes no sense to still use it
for releases.

- Provide a tarball with the docs and doxygen as part of the release.

There's some of that already, though it never worked too well on my
builds. I never cared, maybe I should.

- PGP signatures on pre-built binaries: the person who builds the
binary should sign it (unless you think this is too involved).

I'm ok with this, but we need some process documentation, so that all
of us releasing binaries do the exact same thing or users will be
confused.

- Not including Dragonegg in the release; it seems pretty unmaintaned by now.

I already don't for a long time... Maybe ever. :slight_smile:

In my wish-list for test-release, in addition to yours, is:

1. Check that all dependencies are met. Libraries, tools, Python
modules, header files, etc. CMake will do most of it, so that may be
covered by the move to it.

2. Check that the things you want to build are actually build. The
script checks out everything (including dragonegg and libc++), but my
final binaries never had any of them. Not even compiler-rt. This one I
*will* start caring *very* soon. I'd like to have both RT and libcxx
for 3.7.

3. Actually running the test-suite on the Phase3/install binaries. But
for now, this is not priority for 3.7. I already have a script to do
that on the side, similar to my new CMake test-suite buildbot [1].

cheers,
--renato

[1] http://lab.llvm.org:8011/builders/clang-native-arm-lnt

4

> - Using CMake for the release binaries. I think I promised we'd do
> this for 3.7. I haven't actually started looking at this yet, but I'm
> still optimistic.

I'm absolutely in agreement with this. Most of us already use CMake
for development, a lot of the buildbots are based on it and I think we
all agree that autoconf is deprecated. Makes no sense to still use it
for releases.

I have mixed opinions on it. For the 32-bit Mips packages I normally do it's definitely a good thing (it allows me to ship sanitizers for one). However, I'm hoping to do Mips64 packages too and I recently discovered cmake problems with Mips64 and find_library(). I don't think this should stop everyone switching over to cmake but it would be good to retain the option of autoconf for a bit longer.

2. Check that the things you want to build are actually build. The
script checks out everything (including dragonegg and libc++), but my
final binaries never had any of them. Not even compiler-rt. This one I
*will* start caring *very* soon. I'd like to have both RT and libcxx
for 3.7.

I was surprised by the lack of compiler-rt in the Mips packages too. It turned out that only X86 built compiler-rt in an autoconf-based build.

5

I have mixed opinions on it. For the 32-bit Mips packages I normally do it's definitely a good thing (it allows me to ship sanitizers for one). However, I'm hoping to do Mips64 packages too and I recently discovered cmake problems with Mips64 and find_library(). I don't think this should stop everyone switching over to cmake but it would be good to retain the option of autoconf for a bit longer.

That's a good point.

I was surprised by the lack of compiler-rt in the Mips packages too. It turned out that only X86 built compiler-rt in an autoconf-based build.

Because I haven't integrated RT and libcxx well enough into Clang on
ARM/AArch64, I haven't bothered getting them in the binary tarball.
Our binary distribution was more of a proof of validation than drop-in
replacement for anything, anyway. I normally let the job of getting
all the deps in the right place for distro folks.

But now that we are validating them all on both ARM and AArch64, it's
about time to make sure they work well in the binary distribution as
well. But I can't do that using autoconf.

cheers,
--renato

6

I started looking at the script yesterday, and my plan is to make it
capable of using both cmake and autoconf for now, since e.g.
compiler-rt doesn't build with CMake on Darwin.

- Hans

7

Yeah, and compiler-rt doesn't build with autoconf on ARM Linux. :slight_smile:

--renato