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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@268631 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@264663 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260040 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260037 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257764 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256791 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@244123 91177308-0d34-0410-b5e6-96231b3b80d8
Looks like the rebased version that Mehdi committed didn't incorporate
the latest changes.
Patch by Erik de Castro Lopo <erikd@mega-nerd.com>!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@243942 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@241138 91177308-0d34-0410-b5e6-96231b3b80d8
* 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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@232278 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@224129 91177308-0d34-0410-b5e6-96231b3b80d8
auroraux.org is not resolving.
I will add this to the release notes as soon as I figure out where to put the
3.6 release notes :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215645 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214565 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213300 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203728 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202603 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202486 91177308-0d34-0410-b5e6-96231b3b80d8
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".
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202430 91177308-0d34-0410-b5e6-96231b3b80d8
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. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202375 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202373 91177308-0d34-0410-b5e6-96231b3b80d8
actually looks like the table on the webpage and is entertainingly
smaller, easier to read, and easier to edit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202371 91177308-0d34-0410-b5e6-96231b3b80d8
