This backend was supposed to generate C++ code which will re-construct
the LLVM IR passed as input. This seems to me to have very marginal
usefulness in the first place.
However, the code has never been updated to use IRBuilder, which makes
its current value negative -- people who look at the output may be
steered to use the *wrong* C++ APIs to construct IR.
Furthermore, it's generated code that doesn't compile since at least
2013.
Differential Revision: http://reviews.llvm.org/D19942
llvm-svn: 268631
r260042 removed a footnote referring to autoconf, but it left
around one item still referring to that footnote (libtool), and
it didn't renumber the later footnote reference.
llvm-svn: 264663
This just incrementally improves what was already there; it's questionable whether this content belongs in the getting started guide at all.
Patch by Ben Nathanson w/permission w/minor edtis by me.
llvm-svn: 260040
The mentioned environment variable doesn't appear to have any use in the LLVM repository. If it is still relevant for clang, we can consider adding it to the clang getting started page.
Patch inspired by documentation work by Ben Nathanson at the LLVM Bloomberg sprint.
llvm-svn: 260037
Phabricator to trunk.
The previous documentation had a few issues:
* It did not make it explicit that code could be
committed without using the Arcanist tool and how this should be done.
* There was also an implicit assumption on using Subversion
rather than git-svn in the example using Arcanist. The documentation now
explicitly mentions both cases and details how to commit to trunk in
each case.
Reviewers: klimek, probinson
Subscribers: probinson, nwilson, reames, llvm-commits
Differential Revision: http://reviews.llvm.org/D15801
llvm-svn: 257764
CMake v3.2 or newer is necessary to get interactive output when running
Lit via Ninja. Otherwise Ninja will buffer Lit's output, which makes
for a crummy experience -- you can't tell if your tests are hung!
Patch by Justin Lebar!
llvm-svn: 256791
Patch turns on OpenMP support in clang by default after fixing OpenMP buildbots.
Differential Revision: http://reviews.llvm.org/D13802
llvm-svn: 255222
Since the docs were written, we've added the BPF backend to the list.
Updating the docs to take this in to account. Also sorted them to
match cmake while I was changing these lines.
Reviewed by Chris B.
llvm-svn: 244123
Looks like the rebased version that Mehdi committed didn't incorporate
the latest changes.
Patch by Erik de Castro Lopo <erikd@mega-nerd.com>!
llvm-svn: 243942
Summary: Download should be over https, not insecure ftp at least for the signature and key files. The signature should also get verified.
Test Plan: None
Reviewers: chandlerc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D10845
llvm-svn: 241138
* Moved autotools configure & build example out of "Getting Started Quickly (A Summary)" and into BuildingLLVMWithAutoTools.
* Removed the annotations that CMake is the recommended process and Autotools is alternate.
* Added brief documentation about build targets under "Getting Started Quickly..."
* Added Overview text to BuildingLLVMWithAutotools
* Fixed up a broken link.
llvm-svn: 232278
We were already requiring 2.5, which meant that people on old linux distros
had to upgrade anyway.
Requiring python 2.6 will make supporting 3.X easier as we can use the 3.X
exception syntax.
According to the discussion on llvmdev, there is not much value is requiring
just 2.6, we may as well just require 2.7.
llvm-svn: 224129
Users keep emailing us about the difficulties of getting LD_LIBRARY_PATH
into their environment, which should be completely unecessary. Try to
strengthen the rpath recommentation by putting in an example cmake
invocation.
Speaking of which, we might want to make CMake the recommended build
system in GettingStarted.html.
llvm-svn: 214565
This optional dependency on the udis86 library was added some time back to aid
JIT development, but doesn't make much sense to link into LLVM binaries these
days.
llvm-svn: 213300
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
Chris Bieneman