| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getting started guide.
Some highlights:
- I heard there was this Clang compiler that you could use for your
host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.
There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.
llvm-svn: 202370
|
|
|
|
|
|
| |
build LLD.
llvm-svn: 200758
|
|
|
|
|
|
| |
PR17608
llvm-svn: 193491
|
|
|
|
| |
llvm-svn: 192304
|
|
|
|
| |
llvm-svn: 191425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
part of getting started with LLVM.
The LLVM getting started document is in woeful need of attention. I may
get to some of this, but some random notes for folks interested:
1) We need to separate the getting started steps for folks who are
interested in the core LLVM libs and nothing else, folks interested
in a nifty C++ toolchain and nothing else, and folks interested in
both.
2) We should include documentation for both release archives, svn, and
git in equal portion, and we should document all of the various
repositories of interest: llvm, clang, clang-tools-extra,
compiler-rt, lld, libcxx, test-suite.
3) We should document the CMake build. We should probably document the
CMake build first, and give a fall-back set of docs for the Makefile
build for the use cases where that is still the preferred solution.
This would more closely match the use cases that folks in the open
source community are likely to have, and would remove a point of
discrepancy between Linux, Windows, and Mac instructions.
4) Probably a ton of other modernization stuff that I've not thought of
here.
Anyways, if anyone at all is interested, please help clean up this
document. It is much needed.
llvm-svn: 189732
|
|
|
|
| |
llvm-svn: 188589
|
|
|
|
|
|
| |
Approval in here http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/064169.html
llvm-svn: 187145
|
|
|
|
| |
llvm-svn: 183761
|
|
|
|
| |
llvm-svn: 182496
|
|
|
|
|
|
|
|
|
|
| |
This patch wires up the SystemZ target in configure, so that it can now be
built using --enable-targets=systemz. It is not yet included in the default
build (--enable-targets=all); this will be done by a follow-up patch.
Patch by Richard Sandiford.
llvm-svn: 181208
|
|
|
|
|
|
| |
instead of catting it into the documentation itself.
llvm-svn: 180589
|
|
|
|
|
|
| |
compression/uncompression in selected LLVM tools.
llvm-svn: 180083
|
|
|
|
| |
llvm-svn: 178254
|
|
|
|
|
|
| |
Patch by Thomas Schwinge.
llvm-svn: 177876
|
|
|
|
|
| |
Contributed-by: Thomas Schwinge <thomas@codesourcery.com>
llvm-svn: 177841
|
|
|
|
| |
llvm-svn: 176096
|
|
|
|
| |
llvm-svn: 176090
|
|
|
|
| |
llvm-svn: 173478
|
|
|
|
|
|
|
| |
custom git script called git-svnup which handles all of the work of
using the git-mirrors/keeping the git-svn numbers in sync.
llvm-svn: 173472
|
|
|
|
|
|
| |
We don't have DejaGNU tests now.
llvm-svn: 172836
|
|
|
|
|
|
|
|
|
| |
Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.
This fixes PR14891 as a special case.
llvm-svn: 172162
|
|
|
|
|
|
| |
PR14889
llvm-svn: 172046
|
|
|
|
| |
llvm-svn: 171729
|
|
|
|
|
|
| |
is actually used by a few Linux distributions
llvm-svn: 171671
|
|
|
|
|
| |
Signed-off-by: Renato Golin <renato.golin@linaro.org>
llvm-svn: 171642
|
|
|
|
|
|
| |
'clang' to use it as the compiler.
llvm-svn: 171630
|
|
|
|
|
|
|
|
|
|
| |
This is a pretty lengthy document, so put the table of contents in your
face so that it's easier to scope out the content.
This document is a mess currently and needs to be
refactored/revised/split-up.
llvm-svn: 170646
|
|
|
|
|
|
| |
gives a nicer output than 'bash'.
llvm-svn: 169979
|
|
|
|
|
|
| |
Suggested by Sean McBride, thanks!
llvm-svn: 168745
|
|
|
|
|
|
| |
.git/config was marked as "bash" instead of "ini".
llvm-svn: 168365
|
|
|
|
| |
llvm-svn: 168285
|
|
|
|
| |
llvm-svn: 168088
|
|
|
|
| |
llvm-svn: 167979
|
|
|
|
| |
llvm-svn: 165690
|
|
|
|
| |
llvm-svn: 165689
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hypothesis 1: use of `.. code::` directive instead of `.. code-block::`
is causing Sphinx to discard the block. On my machine, `.. code::`
renders fine. However, I don't think that `.. code::` is actually a
legit Sphinx directive. I believe that on my machine Sphinx is falling
back to just displaying it monospace with no syntax, whereas llvm.org's
Sphinx is just discarding it.
This is truly "remote debugging" since I can't reproduce this on my
machine. It would be helpful to be able to see the llvm.org Sphinx
build logs; if that's possible please let me know.
llvm-svn: 165632
|
|
|
|
|
|
|
| |
Found the fix on this page:
http://permalink.gmane.org/gmane.comp.python.sphinx.devel/112
llvm-svn: 165380
|
|
llvm-svn: 165372
|