As an example that was not actually being used, it suffered from a slow bitrot.
The two main issues with it were that it had no cmake support and
included a copy of the autoconf directory. The reality is that
autoconf is not easily composable. The lack of composabilty is why we
have clang options in llvm's configure. Suggesting that users include
a copy of autoconf/ in their projects seems a bad idea.
We are also in the process of switching to cmake, so pushing autoconf
to new project is probably not what we want.
llvm-svn: 203728
The docs now build cleanly. Yay!
The following warnings were fixed:
/home/sean/pg/llvm/llvm/docs/HowToReleaseLLVM.rst:364: WARNING: Enumerated list ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/InAlloca.rst:: WARNING: document isn't included in any toctree
/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.
Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/CodingStandards.rst:85: WARNING: Title underline too short.
Supported C++11 Language and Library Features
-------------------------------------------
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:185: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:565: WARNING: Explicit markup ends without a blank line; unexpected unindent.
/home/sean/pg/llvm/llvm/docs/GettingStarted.rst:567: WARNING: Block quote ends without a blank line; unexpected unindent.
llvm-svn: 202603
a more modern host C++ toolchain for Linux distros where folks sometimes
don't have a good option to get one as part of their system.
This is a first cut, so feedback, testing, and suggestions are very,
very welcom. This is one of the last real documentation changes that was
specifically requested prior to switching LLVM and Clang to build in
C++11 mode by default.
llvm-svn: 202486
seems unlikely to be added. It also doesn't seem like it should be part
of the build system at all (consider out-of-tree builds).
We should probably add nice, easy tool for this that works both for svn
client trees and git-svn client trees, but it probably won't be spelled
"make update".
llvm-svn: 202430
toolchain of LLVM. These are already being enforced by the build system
and have been discussed quite a few times on the lists, but
documentation is important. =]
Also, garbage collect the majority of the information about broken host
GCC toolchains. These aren't really relevant any more as they're all
older than the minimum requirement. I've left a few notes about
compilers one step older than the current requirement as these compilers
are at least conceivable to use, and it's better to preserve this kind
of hard-won institutional knowledge.
The next step will be some specific docs on how to set up a sufficiently
modern host toolchain if your system doesn't come with one. But that'll
be tomorrow. =]
llvm-svn: 202375
bits of software and to use a modern GCC version.
The Subversion bit was weird anyways -- it has nothing to do with
compiling LLVM. Also, there are many other ways to get at the trunk
source (git, git-svn, etc).
The TeXinfo thing... I have no idea about. But you can get a working
LLVM w/o it pretty easily. If man pages or something are missing, that
hardly seems like a problem. If folks really want this back, let me
know, but it seems mostly like a distraction.
I'd still like to separate this into:
- Required software to compile.
- Optional software to compile.
- Required software for certain *contributor* activities (like
regenerating configure scripts).
Also we need to mention that there are multiple options for build
systems, and the differences.
Also we should mention Windows.
Also probably other stuff I'm forgetting.
I'm wondering if this whole thing needs to be shot in the head and we
should just start a new, simpler getting started that doesn't have so
many years of accumulated stuff that is no longer relevant.
llvm-svn: 202373
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
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
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
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
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
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
Sanjay Patel