Use -sFOO rather than -s FOO=1 in documentation. NFC (#16487)

Followup to #16025

Author: sbc100

docs/emcc.txt

@@ -87,26 +87,27 @@ Options that are modified or new in *emcc* are listed below:
 
      For more tips on optimizing your code, see Optimizing Code.
 
-"-s OPTION[=VALUE]"
+"-sOPTION[=VALUE]"
    [different OPTIONs affect at different stages, most at link time]
    Emscripten build options. For the available options, see
    src/settings.js.
 
    Note:
 
-     You can prefix boolean options with "NO_" to reverse them. For
-     example, "-s EXIT_RUNTIME=1" is the same as "-s
-     NO_EXIT_RUNTIME=0".
+     If no value is specifed it will default to "1".
 
    Note:
 
-     If no value is specifed it will default to "1".
+     It is possible, with boolean options, to use the "NO_" prefix to
+     reverse their meaning. For example, "-sEXIT_RUNTIME=0" is the
+     same as "-sNO_EXIT_RUNTIME=1" and vice versa.  This is not
+     recommended in most cases.
 
    Note:
 
      Lists can be specified as comma separated strings:
 
-        -s EXPORTED_FUNCTIONS=foo,bar
+        -sEXPORTED_FUNCTIONS=foo,bar
 
    Note:
 
@@ -115,24 +116,24 @@ Options that are modified or new in *emcc* are listed below:
      and with or without brackets around the list.  For example, all
      the following are equivalent:
 
-        -s EXPORTED_FUNCTIONS="foo","bar"
-        -s EXPORTED_FUNCTIONS=["foo","bar"]
-        -s EXPORTED_FUNCTIONS=[foo,bar]
+        -sEXPORTED_FUNCTIONS="foo","bar"
+        -sEXPORTED_FUNCTIONS=["foo","bar"]
+        -sEXPORTED_FUNCTIONS=[foo,bar]
 
    Note:
 
      For lists that include brackets or quote, you need quotation
      marks (") around the list in most shells (to avoid errors being
      raised). Two examples are shown below:
 
-        -s EXPORTED_FUNCTIONS="['liblib.so']"
-        -s "EXPORTED_FUNCTIONS=['liblib.so']"
+        -sEXPORTED_FUNCTIONS="['liblib.so']"
+        -s"EXPORTED_FUNCTIONS=['liblib.so']"
 
    You can also specify that the value of an option will be read from
    a file. For example, the following will set "EXPORTED_FUNCTIONS"
    based on the contents of the file at **path/to/file**.
 
-      -s EXPORTED_FUNCTIONS=@/path/to/file
+      -sEXPORTED_FUNCTIONS=@/path/to/file
 
    Note:
 
@@ -144,8 +145,9 @@ Options that are modified or new in *emcc* are listed below:
 
    Note:
 
-     Options can be specified as a single argument without a space
-     between the "-s" and option name.  e.g. "-sFOO=1".
+     Options can be specified as a single argument with or without a
+     space between the "-s" and option name.  e.g. "-sFOO" or "-s
+     FOO".
 
 "-g"
    [compile+link] Preserve debug information.
@@ -163,7 +165,7 @@ Options that are modified or new in *emcc* are listed below:
    "FILENAME" if provided, otherwise the same as the wasm file but
    with suffix ".debug.wasm". While the main file contains no debug
    info, it does contain a URL to where the debug file is, so that
-   devtools can find it. You can use "-s SEPARATE_DWARF_URL=URL" to
+   devtools can find it. You can use "-sSEPARATE_DWARF_URL=URL" to
    customize that location (this is useful if you want to host it on a
    different server, for example).
 
@@ -211,7 +213,7 @@ Options that are modified or new in *emcc* are listed below:
 
    Note:
 
-     When used with "-s WASM=2", two symbol files are created.
+     When used with "-sWASM=2", two symbol files are created.
      "[name].js.symbols" (with WASM symbols) and
      "[name].wasm.js.symbols" (with ASM.js symbols)
 
@@ -235,7 +237,7 @@ Options that are modified or new in *emcc* are listed below:
 
    Note:
 
-     * Consider using "-s MODULARIZE=1" when using closure, as it
+     * Consider using "-sMODULARIZE" when using closure, as it
        minifies globals to names that might conflict with others in
        the global scope. "MODULARIZE" puts all the output into a
        function (see "src/settings.js").
@@ -536,7 +538,7 @@ Options that are modified or new in *emcc* are listed below:
 "--threadprofiler"
    [link] Embeds a thread activity profiler onto the generated page.
    Use this to profile the application usage of pthreads when
-   targeting multithreaded builds (-s USE_PTHREADS=1/2).
+   targeting multithreaded builds (-sUSE_PTHREADS=1/2).
 
 "--em-config <path>"
    [general] Specifies the location of the **.emscripten**

site/source/docs/api_reference/Filesystem-API.rst

@@ -38,9 +38,9 @@ Including File System Support
 
 Emscripten decides whether to include file system support automatically. Many programs don't need files, and file system support is not negligible in size, so Emscripten avoids including it when it doesn't see a reason to. That means that if your C/C++ code does not access files, then  the ``FS`` object and other file system APIs will not be included in the output. And, on the other hand, if your C/C++ code does use files, then file system support will be automatically included. So normally things will "just work" and you don't need to think about this at all.
 
-However, if your C/C++ code doesn't use files, but you want to use them from JavaScript, then you can build with ``-s FORCE_FILESYSTEM=1``, which will make the compiler include file system support even though it doesn't see it being used.
+However, if your C/C++ code doesn't use files, but you want to use them from JavaScript, then you can build with ``-sFORCE_FILESYSTEM``, which will make the compiler include file system support even though it doesn't see it being used.
 
-On the other hand, if you want to **not** include any filesystem support code (which may be included even due to printf or iostreams, due to how musl and libc++ are structured), you can build with ``-s FILESYSTEM=0``. Very simple stdout support will be included if necessary in such a case, enough for printf and such to work, but no filesystem code will be added, which can save a significant amount of code size.
+On the other hand, if you want to **not** include any filesystem support code (which may be included even due to printf or iostreams, due to how musl and libc++ are structured), you can build with ``-sFILESYSTEM=0``. Very simple stdout support will be included if necessary in such a case, enough for printf and such to work, but no filesystem code will be added, which can save a significant amount of code size.
 
 
 .. _filesystem-api-persist-data:

site/source/docs/api_reference/emscripten.h.rst

@@ -270,7 +270,7 @@ Functions
 
 .. c:function:: void emscripten_run_script(const char *script)
 
-  Interface to the underlying JavaScript engine. This function will ``eval()`` the given script. Note: If ``-s DYNAMIC_EXECUTION=0`` is set, this function will not be available.
+  Interface to the underlying JavaScript engine. This function will ``eval()`` the given script. Note: If ``-sDYNAMIC_EXECUTION=0`` is set, this function will not be available.
 
   This function can be called from a pthread, and it is executed in the scope of the Web Worker that is hosting the pthread. To evaluate a function in the scope of the main runtime thread, see the function emscripten_sync_run_in_main_runtime_thread().
 
@@ -281,7 +281,7 @@ Functions
 
 .. c:function:: int emscripten_run_script_int(const char *script)
 
-  Interface to the underlying JavaScript engine. This function will ``eval()`` the given script. Note: If ``-s DYNAMIC_EXECUTION=0`` is set, this function will not be available.
+  Interface to the underlying JavaScript engine. This function will ``eval()`` the given script. Note: If ``-sDYNAMIC_EXECUTION=0`` is set, this function will not be available.
 
   This function can be called from a pthread, and it is executed in the scope of the Web Worker that is hosting the pthread. To evaluate a function in the scope of the main runtime thread, see the function emscripten_sync_run_in_main_runtime_thread().
 
@@ -293,7 +293,7 @@ Functions
 
 .. c:function:: char *emscripten_run_script_string(const char *script)
 
-  Interface to the underlying JavaScript engine. This function will ``eval()`` the given script. Note that this overload uses a single buffer shared between calls. Note: If ``-s DYNAMIC_EXECUTION=0`` is set, this function will not be available.
+  Interface to the underlying JavaScript engine. This function will ``eval()`` the given script. Note that this overload uses a single buffer shared between calls. Note: If ``-sDYNAMIC_EXECUTION=0`` is set, this function will not be available.
 
   This function can be called from a pthread, and it is executed in the scope of the Web Worker that is hosting the pthread. To evaluate a function in the scope of the main runtime thread, see the function emscripten_sync_run_in_main_runtime_thread().
 
@@ -481,7 +481,7 @@ Functions
 
   The difference is that ``emscripten_force_exit`` will shut down the runtime even if you previously called :c:func:`emscripten_exit_with_live_runtime` or otherwise kept the runtime alive. In other words, this method gives you the option to completely shut down the runtime after it was kept alive beyond the completion of ``main()``.
 
-  Note that if ``EXIT_RUNTIME`` is not set (which is the case by default) then the runtime cannot be shut down, as we do not include the code to do so. Build with ``-s EXIT_RUNTIME=1`` if you want to be able to exit the runtime.
+  Note that if ``EXIT_RUNTIME`` is not set (which is the case by default) then the runtime cannot be shut down, as we do not include the code to do so. Build with ``-sEXIT_RUNTIME`` if you want to be able to exit the runtime.
 
   :param int status: The same as for the *libc* function `exit() <http://linux.die.net/man/3/exit>`_.
 
@@ -1054,7 +1054,7 @@ Functions
 
   For this command to work, you must build with the following compiler option (as we do not want to increase the build size with this metadata): ::
 
-    -s RETAIN_COMPILER_SETTINGS=1
+    -sRETAIN_COMPILER_SETTINGS
 
   :param name: The compiler setting to return.
   :type name: const char*
@@ -1066,7 +1066,7 @@ Functions
   Returns whether pseudo-synchronous functions can be used.
 
   :rtype: int
-  :returns: 1 if program was compiled with ASYNCIFY=1, 0 otherwise.
+  :returns: 1 if program was compiled with -sASYNCIFY, 0 otherwise.
 
 
 .. c:function:: void emscripten_debugger()
@@ -1279,7 +1279,7 @@ Typedefs
 Pseudo-synchronous functions
 ============================
 
-These functions require Asyncify (``-s ASYNCIFY=1``). These functions are asynchronous but appear synchronous in C. See `Asyncify <https://emscripten.org/docs/porting/asyncify.html>`_ for more details.
+These functions require Asyncify (``-sASYNCIFY``). These functions are asynchronous but appear synchronous in C. See `Asyncify <https://emscripten.org/docs/porting/asyncify.html>`_ for more details.
 
 Sleeping
 --------
@@ -1412,7 +1412,7 @@ Functions
     including rarely-used functions, in which case the lazy-loading may
     not happen at all.
 
-  .. note:: This requires building with ``-s ASYNCIFY_LAZY_LOAD_CODE``.
+  .. note:: This requires building with ``-sASYNCIFY_LAZY_LOAD_CODE``.
 
 ABI functions
 =============

site/source/docs/api_reference/fetch.rst

@@ -12,8 +12,8 @@ network requests can be run either synchronously or asynchronously as desired.
 
 .. note::
 
-  In order to use the Fetch API, you would need to compile your code with ``-s
-  FETCH=1``.
+  In order to use the Fetch API, you would need to compile your code with
+  ``-sFETCH``.
 
 Introduction
 ============
@@ -195,9 +195,9 @@ emscripten_fetch() returns.
   - **No flags**: Only asynchronous Fetch operations are available.
   - ``--proxy-to-worker``: Synchronous Fetch operations are allowed for fetches
     that only do an XHR but do not interact with IndexedDB.
-  - ``-s USE_PTHREADS=1``: Synchronous Fetch operations are available on
+  - ``-sUSE_PTHREADS``: Synchronous Fetch operations are available on
     pthreads, but not on the main thread.
-  - ``--proxy-to-worker`` + ``-s USE_PTHREADS=1``: Synchronous Fetch operations
+  - ``--proxy-to-worker`` + ``-sUSE_PTHREADS``: Synchronous Fetch operations
     are available both on the main thread and pthreads.
 
 Waitable Fetches
@@ -242,9 +242,9 @@ issuing thread can perform some other work until the fetch completes.
   Waitable fetches are available only in certain build modes:
 
   - **No flags** or ``--proxy-to-worker``: Waitable fetches are not available.
-  - ``-s USE_PTHREADS=1``: Waitable fetches are available on pthreads, but not
+  - ``-sUSE_PTHREADS``: Waitable fetches are available on pthreads, but not
     on the main thread.
-  - ``--proxy-to-worker`` + ``-s USE_PTHREADS=1``: Waitable fetches are
+  - ``--proxy-to-worker`` + ``-sUSE_PTHREADS``: Waitable fetches are
     available on all threads.
 
 Tracking Progress