1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-22 10:42:39 +01:00

Documentation: use a 'console' highlighter for terminal output examples. This

gives a nicer output than 'bash'.

llvm-svn: 169979
This commit is contained in:
Dmitri Gribenko 2012-12-12 13:56:37 +00:00
parent dd5710ee32
commit 8a382641f3
2 changed files with 37 additions and 37 deletions

View File

@ -79,7 +79,7 @@ grabbing the wrong linker/assembler/etc, there are two ways to fix it:
#. Run ``configure`` with an alternative ``PATH`` that is correct. In a
Bourne compatible shell, the syntax would be:
.. code-block:: bash
.. code-block:: console
% PATH=[the path without the bad program] ./configure ...
@ -106,7 +106,7 @@ I've modified a Makefile in my source tree, but my build tree keeps using the ol
If the Makefile already exists in your object tree, you can just run the
following command in the top level directory of your object tree:
.. code-block:: bash
.. code-block:: console
% ./config.status <relative path to Makefile>;
@ -133,13 +133,13 @@ This is most likely occurring because you built a profile or release
For example, if you built LLVM with the command:
.. code-block:: bash
.. code-block:: console
% gmake ENABLE_PROFILING=1
...then you must run the tests with the following commands:
.. code-block:: bash
.. code-block:: console
% cd llvm/test
% gmake ENABLE_PROFILING=1
@ -175,17 +175,17 @@ After Subversion update, rebuilding gives the error "No rule to make target".
-----------------------------------------------------------------------------
If the error is of the form:
.. code-block:: bash
.. code-block:: console
gmake[2]: *** No rule to make target `/path/to/somefile',
needed by `/path/to/another/file.d'.
needed by `/path/to/another/file.d'.
Stop.
This may occur anytime files are moved within the Subversion repository or
removed entirely. In this case, the best solution is to erase all ``.d``
files, which list dependencies for source files, and rebuild:
.. code-block:: bash
.. code-block:: console
% cd $LLVM_OBJ_DIR
% rm -f `find . -name \*\.d`

View File

@ -505,7 +505,7 @@ directory:
If you would like to get the LLVM test suite (a separate package as of 1.4), you
get it from the Subversion repository:
.. code-block:: bash
.. code-block:: console
% cd llvm/projects
% svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
@ -523,13 +523,13 @@ marks (so, you can recreate git-svn metadata locally). Note that right now
mirrors reflect only ``trunk`` for each project. You can do the read-only GIT
clone of LLVM via:
.. code-block:: bash
.. code-block:: console
% git clone http://llvm.org/git/llvm.git
If you want to check out clang too, run:
.. code-block:: bash
.. code-block:: console
% git clone http://llvm.org/git/llvm.git
% cd llvm/tools
@ -540,7 +540,7 @@ pull --rebase`` instead of ``git pull`` to avoid generating a non-linear history
in your clone. To configure ``git pull`` to pass ``--rebase`` by default on the
master branch, run the following command:
.. code-block:: bash
.. code-block:: console
% git config branch.master.rebase true
@ -553,13 +553,13 @@ Assume ``master`` points the upstream and ``mybranch`` points your working
branch, and ``mybranch`` is rebased onto ``master``. At first you may check
sanity of whitespaces:
.. code-block:: bash
.. code-block:: console
% git diff --check master..mybranch
The easiest way to generate a patch is as below:
.. code-block:: bash
.. code-block:: console
% git diff master..mybranch > /path/to/mybranch.diff
@ -570,14 +570,14 @@ could be accepted with ``patch -p1 -N``.
But you may generate patchset with git-format-patch. It generates by-each-commit
patchset. To generate patch files to attach to your article:
.. code-block:: bash
.. code-block:: console
% git format-patch --no-attach master..mybranch -o /path/to/your/patchset
If you would like to send patches directly, you may use git-send-email or
git-imap-send. Here is an example to generate the patchset in Gmail's [Drafts].
.. code-block:: bash
.. code-block:: console
% git format-patch --attach master..mybranch --stdout | git imap-send
@ -603,7 +603,7 @@ For developers to work with git-svn
To set up clone from which you can submit code using ``git-svn``, run:
.. code-block:: bash
.. code-block:: console
% git clone http://llvm.org/git/llvm.git
% cd llvm
@ -622,7 +622,7 @@ To set up clone from which you can submit code using ``git-svn``, run:
To update this clone without generating git-svn tags that conflict with the
upstream git repo, run:
.. code-block:: bash
.. code-block:: console
% git fetch && (cd tools/clang && git fetch) # Get matching revisions of both trees.
% git checkout master
@ -640,7 +640,7 @@ The git-svn metadata can get out of sync after you mess around with branches and
``dcommit``. When that happens, ``git svn dcommit`` stops working, complaining
about files with uncommitted changes. The fix is to rebuild the metadata:
.. code-block:: bash
.. code-block:: console
% rm -rf .git/svn
% git svn rebase -l
@ -722,13 +722,13 @@ To configure LLVM, follow these steps:
#. Change directory into the object root directory:
.. code-block:: bash
.. code-block:: console
% cd OBJ_ROOT
#. Run the ``configure`` script located in the LLVM source tree:
.. code-block:: bash
.. code-block:: console
% SRC_ROOT/configure --prefix=/install/path [other options]
@ -764,7 +764,7 @@ Profile Builds
Once you have LLVM configured, you can build it by entering the *OBJ_ROOT*
directory and issuing the following command:
.. code-block:: bash
.. code-block:: console
% gmake
@ -775,7 +775,7 @@ If you have multiple processors in your machine, you may wish to use some of the
parallel build options provided by GNU Make. For example, you could use the
command:
.. code-block:: bash
.. code-block:: console
% gmake -j2
@ -857,7 +857,7 @@ For instructions on how to install Sphinx, see
After following the instructions there for installing Sphinx, build the LLVM
HTML documentation by doing the following:
.. code-block:: bash
.. code-block:: console
$ cd SRC_ROOT/docs
$ make -f Makefile.sphinx
@ -893,13 +893,13 @@ This is accomplished in the typical autoconf manner:
* Change directory to where the LLVM object files should live:
.. code-block:: bash
.. code-block:: console
% cd OBJ_ROOT
* Run the ``configure`` script found in the LLVM source directory:
.. code-block:: bash
.. code-block:: console
% SRC_ROOT/configure
@ -945,7 +945,7 @@ module, and you have root access on the system, you can set your system up to
execute LLVM bitcode files directly. To do this, use commands like this (the
first command may not be required if you are already using the module):
.. code-block:: bash
.. code-block:: console
% mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
% echo ':llvm:M::BC::/path/to/lli:' > /proc/sys/fs/binfmt_misc/register
@ -955,7 +955,7 @@ first command may not be required if you are already using the module):
This allows you to execute LLVM bitcode files directly. On Debian, you can also
use this command instead of the 'echo' command above:
.. code-block:: bash
.. code-block:: console
% sudo update-binfmts --install llvm /path/to/lli --magic 'BC'
@ -1246,7 +1246,7 @@ Example with clang
#. Next, compile the C file into a native executable:
.. code-block:: bash
.. code-block:: console
% clang hello.c -o hello
@ -1257,7 +1257,7 @@ Example with clang
#. Next, compile the C file into a LLVM bitcode file:
.. code-block:: bash
.. code-block:: console
% clang -O3 -emit-llvm hello.c -c -o hello.bc
@ -1267,13 +1267,13 @@ Example with clang
#. Run the program in both forms. To run the program, use:
.. code-block:: bash
.. code-block:: console
% ./hello
and
.. code-block:: bash
.. code-block:: console
% lli hello.bc
@ -1282,27 +1282,27 @@ Example with clang
#. Use the ``llvm-dis`` utility to take a look at the LLVM assembly code:
.. code-block:: bash
.. code-block:: console
% llvm-dis < hello.bc | less
#. Compile the program to native assembly using the LLC code generator:
.. code-block:: bash
.. code-block:: console
% llc hello.bc -o hello.s
#. Assemble the native assembly language file into a program:
.. code-block:: bash
.. code-block:: console
**Solaris:** % /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native
% /opt/SUNWspro/bin/cc -xarch=v9 hello.s -o hello.native # On Solaris
**Others:** % gcc hello.s -o hello.native
% gcc hello.s -o hello.native # On others
#. Execute the native code program:
.. code-block:: bash
.. code-block:: console
% ./hello.native