c:`load`. See `the tests `_ for good examples of using this function. Sources may omit two required parts of a typical non-inline C++ extension: the necessary header includes, as well as the (pybind11) binding code. More precisely, strings passed to ``cpp_sources`` are first concatenated into a single ``.cpp`` file. This file is then prepended with ``#include ``. Furthermore, if the ``functions`` argument is supplied, bindings will be automatically generated for each function specified. ``functions`` can either be a list of function names, or a dictionary mapping from function names to docstrings. If a list is given, the name of each function is used as its docstring. The sources in ``cuda_sources`` are concatenated into a separate ``.cu`` file and prepended with ``torch/types.h``, ``cuda.h`` and ``cuda_runtime.h`` includes. The ``.cpp`` and ``.cu`` files are compiled separately, but ultimately linked into a single library. Note that no bindings are generated for functions in ``cuda_sources`` per se. To bind to a CUDA kernel, you must create a C++ function that calls it, and either declare or define this C++ function in one of the ``cpp_sources`` (and include its name in ``functions``). See :func:`load` for a description of arguments omitted below. Args: cpp_sources: A string, or list of strings, containing C++ source code. cuda_sources: A string, or list of strings, containing CUDA source code. functions: A list of function names for which to generate function bindings. If a dictionary is given, it should map function names to docstrings (which are otherwise just the function names). with_cuda: Determines whether CUDA headers and libraries are added to the build. If set to ``None`` (default), this value is automatically determined based on whether ``cuda_sources`` is provided. Set it to ``True`` to force CUDA headers and libraries to be included. with_pytorch_error_handling: Determines whether pytorch error and warning macros are handled by pytorch instead of pybind. To do this, each function ``foo`` is called via an intermediary ``_safe_foo`` function. This redirection might cause issues in obscure cases of cpp. This flag should be set to ``False`` when this redirect causes issues. Example: >>> # xdoctest: +REQUIRES(env:TORCH_DOCTEST_CPP_EXT) >>> from torch.utils.cpp_extension import load_inline >>> source = """ at::Tensor sin_add(at::Tensor x, at::Tensor y) { return x.sin() + y.sin(); } """ >>> module = load_inline(name='inline_extension', ... cpp_sources=[source], ... functions=['sin_add']) .. note:: By default, the Ninja backend uses #CPUS + 2 workers to build the extension. This may use up too many resources on some systems. One can control the number of workers by setting the `MAX_JOBS` environment variable to a non-negative number. r