Removes many fake idx entries.
These *fake* entries are not needed any more now that the table of contents of documentation files appear in the index.
This commit is contained in:
Grzegorz Adam Hankiewicz
parent
1f4f5d27ee
commit
61ded5ab60
9 changed files with 167 additions and 167 deletions
|
|
@ -116,7 +116,7 @@ The default build of a project is a `debug build`:idx:. To compile a
|
|||
Search path handling
|
||||
--------------------
|
||||
|
||||
Nimrod has the concept of a global `search path`:idx: (PATH) that is queried to
|
||||
Nimrod has the concept of a global search path (PATH) that is queried to
|
||||
determine where to find imported modules or include files. If multiple files are
|
||||
found an ambiguity error is produced.
|
||||
|
||||
|
|
@ -174,7 +174,7 @@ is not shared between different projects.
|
|||
Cross compilation
|
||||
=================
|
||||
|
||||
To `cross compile`:idx:, use for example::
|
||||
To cross compile, use for example::
|
||||
|
||||
nimrod c --cpu:i386 --os:linux --compile_only --gen_script myproject.nim
|
||||
|
||||
|
|
@ -200,7 +200,7 @@ DLL generation
|
|||
|
||||
Nimrod supports the generation of DLLs. However, there must be only one
|
||||
instance of the GC per process/address space. This instance is contained in
|
||||
``nimrtl.dll``. This means that every generated Nimrod `DLL`:idx: depends
|
||||
``nimrtl.dll``. This means that every generated Nimrod DLL depends
|
||||
on ``nimrtl.dll``. To generate the "nimrtl.dll" file, use the command::
|
||||
|
||||
nimrod c -d:release lib/nimrtl.nim
|
||||
|
|
@ -251,7 +251,7 @@ generator and are subject to change.
|
|||
|
||||
NoDecl pragma
|
||||
-------------
|
||||
The `noDecl`:idx: pragma can be applied to almost any symbol (variable, proc,
|
||||
The ``noDecl`` pragma can be applied to almost any symbol (variable, proc,
|
||||
type, etc.) and is sometimes useful for interoperability with C:
|
||||
It tells Nimrod that it should not generate a declaration for the symbol in
|
||||
the C code. For example:
|
||||
|
|
@ -268,7 +268,7 @@ However, the ``header`` pragma is often the better alternative.
|
|||
|
||||
Header pragma
|
||||
-------------
|
||||
The `header`:idx: pragma is very similar to the ``noDecl`` pragma: It can be
|
||||
The ``header`` pragma is very similar to the ``noDecl`` pragma: It can be
|
||||
applied to almost any symbol and specifies that it should not be declared
|
||||
and instead the generated code should contain an ``#include``:
|
||||
|
||||
|
|
@ -287,7 +287,7 @@ encloses the header file in ``""`` in the generated C code.
|
|||
|
||||
IncompleteStruct pragma
|
||||
-----------------------
|
||||
The `incompleteStruct`:idx: pragma tells the compiler to not use the
|
||||
The ``incompleteStruct`` pragma tells the compiler to not use the
|
||||
underlying C ``struct`` in a ``sizeof`` expression:
|
||||
|
||||
.. code-block:: Nimrod
|
||||
|
|
@ -298,7 +298,7 @@ underlying C ``struct`` in a ``sizeof`` expression:
|
|||
|
||||
Compile pragma
|
||||
--------------
|
||||
The `compile`:idx: pragma can be used to compile and link a C/C++ source file
|
||||
The ``compile`` pragma can be used to compile and link a C/C++ source file
|
||||
with the project:
|
||||
|
||||
.. code-block:: Nimrod
|
||||
|
|
@ -311,7 +311,7 @@ of the file.
|
|||
|
||||
Link pragma
|
||||
-----------
|
||||
The `link`:idx: pragma can be used to link an additional file with the project:
|
||||
The ``link`` pragma can be used to link an additional file with the project:
|
||||
|
||||
.. code-block:: Nimrod
|
||||
{.link: "myfile.o".}
|
||||
|
|
@ -319,7 +319,7 @@ The `link`:idx: pragma can be used to link an additional file with the project:
|
|||
|
||||
PassC pragma
|
||||
------------
|
||||
The `passC`:idx: pragma can be used to pass additional parameters to the C
|
||||
The ``passC`` pragma can be used to pass additional parameters to the C
|
||||
compiler like you would using the commandline switch ``--passC``:
|
||||
|
||||
.. code-block:: Nimrod
|
||||
|
|
@ -333,7 +333,7 @@ embed parameters from an external command at compile time:
|
|||
|
||||
PassL pragma
|
||||
------------
|
||||
The `passL`:idx: pragma can be used to pass additional parameters to the linker
|
||||
The ``passL`` pragma can be used to pass additional parameters to the linker
|
||||
like you would using the commandline switch ``--passL``:
|
||||
|
||||
.. code-block:: Nimrod
|
||||
|
|
@ -348,7 +348,7 @@ embed parameters from an external command at compile time:
|
|||
|
||||
Emit pragma
|
||||
-----------
|
||||
The `emit`:idx: pragma can be used to directly affect the output of the
|
||||
The ``emit`` pragma can be used to directly affect the output of the
|
||||
compiler's code generator. So it makes your code unportable to other code
|
||||
generators/backends. Its usage is highly discouraged! However, it can be
|
||||
extremely useful for interfacing with `C++`:idx: or `Objective C`:idx: code.
|
||||
|
|
@ -370,7 +370,7 @@ Example:
|
|||
|
||||
ImportCpp pragma
|
||||
----------------
|
||||
The `importcpp`:idx: pragma can be used to import `C++`:idx: methods. The
|
||||
The ``importcpp`` pragma can be used to import `C++`:idx: methods. The
|
||||
generated code then uses the C++ method calling syntax: ``obj->method(arg)``.
|
||||
In addition with the ``header`` and ``emit`` pragmas this allows *sloppy*
|
||||
interfacing with libraries written in C++:
|
||||
|
|
@ -408,7 +408,7 @@ emits C++ code.
|
|||
|
||||
ImportObjC pragma
|
||||
-----------------
|
||||
The `importobjc`:idx: pragma can be used to import `Objective C`:idx: methods.
|
||||
The ``importobjc`` pragma can be used to import `Objective C`:idx: methods.
|
||||
The generated code then uses the Objective C method calling
|
||||
syntax: ``[obj method param1: arg]``.
|
||||
In addition with the ``header`` and ``emit`` pragmas this allows *sloppy*
|
||||
|
|
@ -458,7 +458,7 @@ emits Objective C code.
|
|||
CodegenDecl pragma
|
||||
------------------
|
||||
|
||||
The `codegenDecl`:idx: pragma can be used to directly influence Nimrod's code
|
||||
The ``codegenDecl`` pragma can be used to directly influence Nimrod's code
|
||||
generator. It receives a format string that determines how the variable or
|
||||
proc is declared in the generated code:
|
||||
|
||||
|
|
@ -473,7 +473,7 @@ proc is declared in the generated code:
|
|||
InjectStmt pragma
|
||||
-----------------
|
||||
|
||||
The `injectStmt`:idx: pragma can be used to inject a statement before every
|
||||
The ``injectStmt`` pragma can be used to inject a statement before every
|
||||
other statement in the current module. It is only supposed to be used for
|
||||
debugging:
|
||||
|
||||
|
|
@ -485,28 +485,28 @@ debugging:
|
|||
|
||||
LineDir option
|
||||
--------------
|
||||
The `lineDir`:idx: option can be turned on or off. If turned on the
|
||||
The ``lineDir`` option can be turned on or off. If turned on the
|
||||
generated C code contains ``#line`` directives. This may be helpful for
|
||||
debugging with GDB.
|
||||
|
||||
|
||||
StackTrace option
|
||||
-----------------
|
||||
If the `stackTrace`:idx: option is turned on, the generated C contains code to
|
||||
If the ``stackTrace`` option is turned on, the generated C contains code to
|
||||
ensure that proper stack traces are given if the program crashes or an
|
||||
uncaught exception is raised.
|
||||
|
||||
|
||||
LineTrace option
|
||||
----------------
|
||||
The `lineTrace`:idx: option implies the ``stackTrace`` option. If turned on,
|
||||
The ``lineTrace`` option implies the ``stackTrace`` option. If turned on,
|
||||
the generated C contains code to ensure that proper stack traces with line
|
||||
number information are given if the program crashes or an uncaught exception
|
||||
is raised.
|
||||
|
||||
Debugger option
|
||||
---------------
|
||||
The `debugger`:idx: option enables or disables the *Embedded Nimrod Debugger*.
|
||||
The ``debugger`` option enables or disables the *Embedded Nimrod Debugger*.
|
||||
See the documentation of endb_ for further information.
|
||||
|
||||
|
||||
|
|
@ -518,7 +518,7 @@ ENDB. See the documentation of `endb <endb.html>`_ for further information.
|
|||
|
||||
Volatile pragma
|
||||
---------------
|
||||
The `volatile`:idx: pragma is for variables only. It declares the variable as
|
||||
The ``volatile`` pragma is for variables only. It declares the variable as
|
||||
``volatile``, whatever that means in C/C++ (its semantics are not well defined
|
||||
in C/C++).
|
||||
|
||||
|
|
@ -530,7 +530,7 @@ DynlibOverride
|
|||
|
||||
By default Nimrod's ``dynlib`` pragma causes the compiler to generate
|
||||
``GetProcAddress`` (or their Unix counterparts)
|
||||
calls to bind to a DLL. With the `dynlibOverride`:idx: command line switch this
|
||||
calls to bind to a DLL. With the ``dynlibOverride`` command line switch this
|
||||
can be prevented and then via ``--passL`` the static library can be linked
|
||||
against. For instance, to link statically against Lua this command might work
|
||||
on Linux::
|
||||
|
|
@ -556,7 +556,7 @@ for further information.
|
|||
Nimrod interactive mode
|
||||
=======================
|
||||
|
||||
The Nimrod compiler supports an `interactive mode`:idx:. This is also known as
|
||||
The Nimrod compiler supports an interactive mode. This is also known as
|
||||
a `REPL`:idx: (*read eval print loop*). If Nimrod has been built with the
|
||||
``-d:useGnuReadline`` switch, it uses the GNU readline library for terminal
|
||||
input management. To start Nimrod in interactive mode use the command
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue