Hi!
The binaries for the 3.3 release candidate 2 are starting to role in. Please take them and give them a go. Please file bug reports for any problems you encounter.
At this point, we are taking fixes only for *serious* regressions from 3.2. I will be pushing back on all requests to merge something into the 3.3 branch. In other words, you will need to do a lot to convince me that we need to go through a third round of testing. 
Share and enjoy!
-bw
Please forgive my ignorance here. Filenames are not what I'm used to
seeing with past versions of Clang....
Below is the process I use to build from sources in the context of
3.2. Does clang+llvm-3.3rc2-x86.tar.gz? include everything I need? Can
I use clang+llvm-3.3rc2-x86.tar.gz, and (a): combine steps (1) and
(2); and (b): omit (4), (5), (6), and (7)?
Or do I need need to use llvm-3.3rc2-source.tar.gz and unpack
clang+llvm-3.3rc2-x86.tar.gz into llvm-3.2.src/tools/ ?
Jeff
1 wget http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz
2 wget http://llvm.org/releases/3.2/clang-3.2.src.tar.gz
3 tar xvf llvm-3.2.src.tar.gz
4 cd llvm-3.2.src/tools
5 tar xvf ../../clang-3.2.src.tar.gz
6 mv clang-3.2.src clang
7 cd ..
8 ./configure --enable-optimized --prefix=/usr/local
9 make -j4
4 cd llvm-3.2.src/tools
5 tar xvf ../../clang-3.2.src.tar.gz
6 mv clang-3.2.src clang
7 cd ..
You don't need to do any of it, there are already symlinks on the llvm.src
dir to point to all others on the same root. Just unpack each source tar
ball and be happy. 
8 ./configure --enable-optimized --prefix=/usr/local
9 make -j4
Neither that. Just go into llvm.src and run ./utils/release/test-release.sh
I have written a doc on how to do that for ARM, maybe that can lead you on
the right direction:
https://wiki.linaro.org/WorkingGroups/ToolChain/LLVM/LLVMRelease
cheers,
--renato
Could you please incorporate this useful document into LLVM's official
documentation? I think that this is good content for encouraging greater
external/downstream involvement in the release process. See
docs/SphinxQuickstartTemplate.rst to get up and running fast.
Also, it's weird (possibly disingenuous) seeing linaro.org saying "we" to
refer to the larger LLVM community (or at least that's how I understand the
"we" in "we aim to release regularly to avoid keeping stable users away
from new features for too long").
-- Sean Silva
Could you please incorporate this useful document into LLVM's official
documentation? I think that this is good content for encouraging greater
external/downstream involvement in the release process. See
docs/SphinxQuickstartTemplate.rst to get up and running fast.
I sure can. I thought there was already a doc on that at LLVM about that.
If there is, would be good to start there.
Also, it's weird (possibly disingenuous) seeing linaro.org saying "we" to
refer to the larger LLVM community (or at least that's how I understand the
"we" in "we aim to release regularly to avoid keeping stable users away
from new features for too long").
That was certainly not the intention. The wiki page I sent wasn't meant to
the LLVM folks, but internally to Linaro, and by "we" I meant "the LLVM
community", trying to explain the LLVM release process to Linaro folks.
I'll reword that phrase to avoid any confusion...
cheers,
--renato
AFAIK, the closest we have is <http://llvm.org/docs/HowToReleaseLLVM.html>,
which details basically what the release manager has to do (i.e., the
audience is LLVM developers, and release managers in particular). I really
liked the article you linked because it seemed to be targeted at an
audience of external developers and packagers, for whom we don't (AFAIK)
really have any docs about the release process, how to get involved, etc.
Since the audience is different, I think it should be its own page
(probably "ReleaseProcess.rst" would be fine, but I don't have a strong
preference).
-- Sean Silva
Hi Sean,
I've created ReleaseProcess.rst, how can I force generation of HTML on the
rst file without rebuilding the whole thing?
cheers,
--renato
The following incantation should work (invoked from docs/):
sphinx-build -b html -d _build/doctrees . _build/html $BUILD_THIS.rst
Basically, this is the command that the makefile executes by default, with
$BUILD_THIS.rst appended. Trailing filenames given to sphinx-build are
interpreted to mean that it should build just those; if given no filenames
(as when invoked by the Makefile), it defaults to building all of them (it
automatically tracks file modification times and does incremental rebuilds,
though).
Note that partial rebuilds may cause Sphinx to not be able to resolve all
inter-document link references if it doesn't have the link targets cached
from a previous full rebuild.
-- Sean Silva
Thanks Sean,
Got in r182759, feel free to add/remove/fix whatever you think it’s appropriate.
cheers,
–renato
Thanks!
-- Sean Silva
Would it be possible to build the binaries with --enable-shared and
REQUIRES_RTTI=1? This would make the binaries more handy for using
the LLVM as a library in external projects. At least the LLVM shared
lib is missing from the x86 RC2 binary package while libclang.so
is there.
In general, I think the guidelines written for the distro packagers
should be applicable for the binary packages as well:
http://llvm.org/docs/Packaging.html
Thanks,
I disagree. The binary release should be as simple and light as LLVM
developers intend the code to be, advanced users can always re-compile the
way they want to suit their needs.
Distributions can create multiple packages to suit multiple needs (like
boost, binutils, vim, eclipse, etc) and this is the main target of those
tips. Not to make every release like that, but how to tune the build to a
particular purpose so distro folks can make the best judgement.
I particularly dislike RTTI and exceptions, but I don't see a big deal on
shared vs. static. Even on memory restricted systems (like embedded ARM),
there's no clear answer. On specialist systems (bare-metal, stripped-down
Linux), having all statically linked is way easier, but on pluggable,
extensible systems, having it shared is better.
Again, this is all about distros, not binary releases. If you're going to
depend on LLVM for production purposes, you better depend on a package
system than our binary releases.
cheers,
--renato
I disagree. The binary release should be as simple and light as LLVM
developers intend the code to be, advanced users can always re-compile the
way they want to suit their needs.
The default build options are optimized for us developers (if
anything) rather than anyone's actual use of LLVM. I tend to agree
with Pekka that the binary packages should be as flexible as possible
(in particular I strongly disagree that anyone's personal preference
for RTTI or its absence should affect what people can use them for).
Realistically, I don't see our binaries being used for much except
experimentation, which we should make as easy as possible. Any
critical project will be building their own (or should, regardless of
what we do with our packages!), and the distributions will carry on
making their own decisions.
As you say, advanced individual users will build from source for their
own requirements, which leaves dabblers who don't want to care about
the details.
Tim.
The default build options are optimized for us developers (if
anything) rather than anyone's actual use of LLVM.
Yes, and this is why...
Realistically, I don't see our binaries being used for much except
experimentation.
Furthermore, while this is true...
which we should make as easy as possible.
Enabling RTTI and Exceptions by default have the undesired side-effect that
core development will, sometimes unintentionally, start using it and we'll
create a necessity, when previously we had the option.
Leaving those options disabled by default have little to do with ease of
use, but with design decisions that I don't think should change, just for
the sake of usability.
Usability can be controlled at a package level (or build level), and that's
the job of the distribution packaging process, or the expert developers,
not the tool itself.
The options are there, and even documented to make the advanced
building/packaging easier, but making that a default is teaching the wrong
lesson.
Our binaries are not used that much to warrant being user-friendly.
Production environments should use pre-packaged binaries, specialized
packages or hand-crafted tar-ballz, and not the "default" binaries.
If anything, those binaries are a reference, to which you'll compare your
specialized build to see what gain you had, or what functionality you're
missing. End users should do none of that, and rely on DEB and RPM
packages, and complain to their distribution managers to pack this or that
feature next time.
cheers,
--renato
Enabling RTTI and Exceptions by default have the undesired side-effect that
core development will, sometimes unintentionally, start using it and we'll
create a necessity, when previously we had the option.
I'm not sure I see why our binaries have to use the default options.
In fact what I wrote was assuming we'd keep our defaults for
development but use something saner for binary packages.
Leaving those options disabled by default have little to do with ease of
use, but with design decisions that I don't think should change, just for
the sake of usability.
But they're our design decisions that we really shouldn't be imposing
on everyone who wants to link against LLVM. If we want to tell
everyone to build their own LLVM then that's fine too, but an even
more efficient way to do that would be to only produce binaries for a
z80 or something.
Our binaries are not used that much to warrant being user-friendly.
What are they used for, if it doesn't warrant being user friendly? As
you say, anyone serious will be building their own. That just leaves
people who want to do some quick checks as far as I can see; surely
they want everything to be as easy as possible. Or why do we bother
with the entire fiasco?
Tim.
If we want to tell everyone to build their own LLVM then that's fine too,
but an even
more efficient way to do that would be to only produce binaries for a
z80 or something.
Er, that's not what I said. I said people should rely on distro packages,
which don't use our binaries at all.
Distros should produce a plethora or packages, suitable for most people.
Not us.
What are they used for, if it doesn't warrant being user friendly? As
you say, anyone serious will be building their own. That just leaves
people who want to do some quick checks as far as I can see; surely
they want everything to be as easy as possible. Or why do we bother
with the entire fiasco?
You're probably getting it wrong, or I am. My view of the utility of these
packages is to:
1. Make sure they get tested as much as they can, and the behaviour of the
standard build (the one we use for development and some production
environments) is stable and correct.
2. Nothing else.
We can't test every single variation, so we test the one makes more sense.
What makes more sense to you, or Pekka, probably doesn't make to me or
someone else. Even the "most" used method can be so alien to the rest of
the community that it has little utility in the real world.
My view is that, building for the least common denominator and testing that
gives everyone else (or at least most part of it) a chance to compare back
to a minimal standard build. In any form or shape, with any set of options
for any target (you surely understand that from an ARM point of view, the
nightmare it is to get it right), we will fail. Miserably.
But this is the kind of thing that distributions get right on the spot.
They have the ability to cross-link dependencies in a way where all that
becomes seamless. They can describe and control dependencies of "llvm-rtti"
and "llvm-shared" in ways we could only dream of. So, why try to reproduce
a behaviour that is clearly a distribution problem only to fail?
People should not be re-compiling the sources all the time, in multiple
ways, and nor should we. Distribution packagers should be doing that for
them.
I don't think there's even a guarantee that those binaries will work on any
given target... That alone should tell you *not* to use them under any
circumstance.
cheers,
--renato
But they’re our design decisions that we really shouldn’t be imposing
OK. If the binary tar balls are not meant for end users but to be merely a
product of the default build options for testing, then this does not matter.
I thought they were provided for user convenience, e.g., when using in
distributions that do not ship/backport new LLVM versions to all their
releases, which is the usual case.
In my case I found it convenient to download a binary package for a Pentium 4
with an Ubuntu 12.04 for which it takes pretty much a day to build it from sources, until I found it doesn't have the shared lib I need (and AFAIU not
the RTTI either). Well, I continue building from the sources like previously,
not a big deal.
On 1 Jun 2013 23:17, “Pekka Jääskeläinen”
In my case I found it convenient to download a binary package for a Pentium 4
with an Ubuntu 12.04 for which it takes pretty much a day to build it from sources, until I found it doesn’t have the shared lib I need (and AFAIU not
the RTTI either). Well, I continue building from the sources like previously,
not a big deal.
Yes, a very specialised case. Can you cross build on a newer machine?
To provide you with shared+RTTI, we’d have to produce and test four different binaries. Include exceptions and you have 8. For each platform, including legacy ones like pentium 4, which not many people can test. Not to mention how long would it take to test on such old machine (6 full builds+test suite at least for every RC).
Cheers,
Renato