Michael Kruse 87cbea6cdc
[openmp][cmake][NFCI] Avoid non-eval uses of ${var} (#182267)
When using

    set(var "Example")
    if (${var})

CMake will first resolve the if-argument to

    if (Example)

And what then happens depends on the existance of a variable with the
name "Example":

1. If instead of "Example", a truth constant is used ("TRUE", "FALSE",
   "ON", "OFF", "", "-NOTFOUND" ...), it is prioritized
   (https://cmake.org/cmake/help/latest/command/if.html#constant)

2. If a variable with the name "Example" exists: Use the truthiness of
   its content
   (https://cmake.org/cmake/help/latest/command/if.html#variable)

3. Otherwise, it is false-y

That is, the the result of the conditional does not only depend on the
content of `var`, but also some other variable. This is usually
unintended and leads to problems such as addressed with #154537. The
only case where this is intended is when passing an expression to be
evaluated such as with `pythonize_bool`, `append_if` and
`libomp_append`. In all other cases, using `${var}` without quotes is a
pattern to be avoided.

Remark:
If `${var}` is not one of the values considered a [truthiness
constant](https://cmake.org/cmake/help/latest/command/if.html#constant),
the result of `if (var)` and `if ("${var}")` is different:

* `if (var)` is true-ish
  (https://cmake.org/cmake/help/latest/command/if.html#variable)

* `if ("Example")` and therefore `if ("${var}")` are false-y
  (https://cmake.org/cmake/help/latest/command/if.html#string)

In this PR I am preferring `if (var)` over `if ("${var}")` because has
less clutter, resembles Python's behaviour, and problably what most
users are expecting, even though `if (${var})` in most cases would
evaluate to false-y because a variable does not exist. This ambiguity
does not exist for STREQUAL and MATCHES.
2026-03-02 13:21:36 +01:00
..

OpenMP LLVM Documentation
==================

OpenMP LLVM's documentation is written in reStructuredText, a lightweight
plaintext markup language (file extension `.rst`). While the
reStructuredText documentation should be quite readable in source form, it
is mostly meant to be processed by the Sphinx documentation generation
system to create HTML pages which are hosted on <https://llvm.org/docs/> and
updated after every commit. Manpage output is also supported, see below.

If you instead would like to generate and view the HTML locally, install
Sphinx <http://sphinx-doc.org/> and then do:

    cd <build-dir>
    cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_HTML=true -DCMAKE_MODULE_PATH=/path/to/llvm/cmake/modules <src-dir>
    make docs-openmp-html
    $BROWSER <build-dir>/docs/html/index.html

The mapping between reStructuredText files and generated documentation is
`docs/Foo.rst` <-> `<build-dir>/projects/openmp/docs//html/Foo.html` <->
`https://openmp.llvm.org/docs/Foo.html`.

If you are interested in writing new documentation, you will want to read
`llvm/docs/SphinxQuickstartTemplate.rst` which will get you writing
documentation very fast and includes examples of the most important
reStructuredText markup syntax.

Manpage Output
===============

Building the manpages is similar to building the HTML documentation. The
primary difference is to use the `man` makefile target, instead of the
default (which is `html`). Sphinx then produces the man pages in the
directory `<build-dir>/docs/man/`.

    cd <build-dir>
    cmake -DLLVM_ENABLE_SPHINX=true -DSPHINX_OUTPUT_MAN=true <src-dir>
    make
    man -l >build-dir>/docs/man/FileCheck.1

The correspondence between .rst files and man pages is
`docs/CommandGuide/Foo.rst` <-> `<build-dir>/projects/openmp/docs//man/Foo.1`.
These .rst files are also included during HTML generation so they are also
viewable online (as noted above) at e.g.
`https://openmp.llvm.org/docs/CommandGuide/Foo.html`.