path: root/doc/howtos.qdoc

/****************************************************************************
**
** Copyright (C) 2018 The Qt Company Ltd.
** Contact: https://www.qt.io/licensing/
**
** This file is part of Qbs.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial License Usage
** Licensees holding valid commercial Qt licenses may use this file in
** accordance with the commercial license agreement provided with the
** Software or, alternatively, in accordance with the terms contained in
** a written agreement between you and The Qt Company. For licensing terms
** and conditions see https://www.qt.io/terms-conditions. For further
** information use the contact form at https://www.qt.io/contact-us.
**
** GNU Free Documentation License Usage
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of
** this file. Please review the following information to ensure
** the GNU Free Documentation License version 1.3 requirements
** will be met: https://www.gnu.org/licenses/fdl-1.3.html.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
    \previouspage custom-modules.html
    \nextpage reference.html
    \page howtos.html

    \title How-tos

    This page provides concrete instructions for common scenarios.

    \list
    \li \l{How do I build a Qt-based project?}
    \li \l{How do I make my app build against my library?}
    \li \l{How do I build release with debug information?}
    \li \l{How do I separate and install debugging symbols?}
    \li \l{How do I use precompiled headers?}
    \li \l{How do I make use of rpaths?}
    \li \l{How do I make sure my generated sources are getting compiled?}
    \li \l{How do I run my autotests?}
    \li \l{How do I use ccache?}
    \li \l{How do I create a module for a third-party library?}
    \li \l{How do I build against libraries that provide pkg-config files?}
    \li \l{How do I create application bundles and frameworks on iOS, macOS, tvOS, and watchOS?}
    \li \l{How do I apply C/C++ preprocessor macros to only a subset of the files in my product?}
    \li \l{How do I disable a compiler warning?}
    \li \l{How do I make the state of my Git repository available to my source files?}
    \li \l{How do I limit the number of concurrent jobs for the linker only?}
    \li \l{How do I add QML files to a project?}
    \li \l{How do I define a reusable Group of files that can be included in other \QBS files?}
    \li \l{How do I print the value of a property?}
    \li \l{How do I debug \QBS scripts?}
    \li \l{How do I sign an application for an Apple platform?}
    \endlist

    \section1 How do I build a Qt-based project?

    First of all, your project files need to declare \l{Depends}{dependencies}
    on \l{Qt} modules.

    To build the project, you need a matching \e profile. The following commands
    set up and use a Qt-specific profile:
    \code
    $ qbs setup-qt /usr/bin/qmake qt
    $ cd my_project
    $ qbs profile:qt
    \endcode
    If you plan to use this profile a lot, consider making it the default one:
    \code
    $ qbs config defaultProfile qt
    $ cd my_project
    $ qbs
    \endcode
    See \l{Managing Qt Versions} for more details.
    \note These instructions are only relevant for building from the command line.
    If you use Qt Creator, profiles are set up automatically from the information in the Kit.

    \section1 How do I make my app build against my library?

    This is achieved by introducing a \e dependency between the two products using the
    \l{Depends} item. Here is a simple, but complete example:
    \code
    Project {
        CppApplication {
            name : "the-app"
            files : [ "main.cpp" ]
            Depends { name: "the-lib" }
        }
        DynamicLibrary {
            name: "the-lib"
            Depends { name: "cpp" }
            files: [
                "lib.cpp",
                "lib.h",
            ]
            Export {
                Depends { name: "cpp" }
                cpp.includePaths: [product.sourceDirectory]
           }
        }
    }
    \endcode

    The product \c the-lib is a dynamic library. It expects other products to build against it, and
    for that purpose, it exports an include path (via an \l{Export} item), so that the
    source files in these products can include the library's header file.

    The product \c the-app is an application that expresses its intent to link against \c the-lib
    by declaring a dependency on it. Now \c main.cpp can include \c lib.h (because of the exported
    include path) and the application binary will link against the library (because the linker
    \l{Rule}{rule} in the \l{cpp} module considers library dependencies as inputs).
    \note In a non-trivial project, the two products would not be defined in the same file.
          Instead, you would put them into files of their own and use the
          \l{Project::references}{Project.references} property to pull them into the project.
          The product definitions would stay exactly the same. In particular, their location
          in the project tree is irrelevant to the relationship between them.

    \section2 Choosing Between Dynamic and Statically-built Qt Projects

    To build \c "the-lib" as either a dynamic or static library, depending on
    how Qt was built, you can use the following code:

    \code
    Product {
        name: "the-lib"
        type: Qt.core.staticBuild ? "staticlibrary" : "dynamiclibrary"

        Depends { name: "Qt.core" }
        // ...
    }
    \endcode

    \section1 How do I build release with debug information?

    You can simply use the \c{"profiling"} \l{qbs::buildVariant}{qbs.buildVariant}:
    \code
    qbs build qbs.buildVariant:profiling
    \endcode

    \section1 How do I separate and install debugging symbols?

    First, you need to set the \l{cpp::debugInformation}{cpp.debugInformation} and
    \l{cpp::separateDebugInformation}{cpp.separateDebugInformation}
    properties to \c true or use some conditional expression in your product:
    \code
    CppApplication {
        // ...
        cpp.debugInformation: qbs.buildVariant !== "release"
        cpp.separateDebugInformation: true
    }
    \endcode

    Now, you can install your \l{Application}{application}, \l{DynamicLibrary}{dynamic library}
    or \l{LoadableModule}{loadable module} among with its debugging symbols as follows:
    \code
    CppApplication {
        // ...
        install: true
        installDir: "bin"
        installDebugInformation: true
        debugInformationInstallDir: "bin"
    }
    \endcode

    If you are not using \l{List of Convenience Items}{convenience items},
    you can install debug symbols manually using the \l{Group} item. If the
    \l{cpp::separateDebugInformation}{cpp.separateDebugInformation} property is set to \c true,
    \QBS will create debugging symbols with the corresponding file tags
    \c "debuginfo_app" (for an application), \c "debuginfo_dll" (for a dynamic library),
    or \c "debuginfo_loadablemodule" (for a macOS plugin).

    \code
    Product {
        type: "application"
        Depends { name: "cpp" }
        cpp.debugInformation: qbs.buildVariant !== "release"
        cpp.separateDebugInformation: true
        Group {
            fileTagsFilter: cpp.separateDebugInformation ? ["debuginfo_app"] : []
            qbs.install: true
            qbs.installDir: "bin"
            qbs.installSourceBase: buildDirectory
        }
    }
    \endcode

    If you're building a shared library, you need to use the \c "debuginfo_dll" tag instead:
    \code
    Product {
        type: "dynamic_library"
        // ...
        Group {
            fileTagsFilter: cpp.separateDebugInformation ? ["debuginfo_dll"] : []
            qbs.install: true
            qbs.installDir: "lib"
            qbs.installSourceBase: buildDirectory
        }
    }
    \endcode

    If you're building a macOS plugin, you need to use the \c "debuginfo_loadablemodule"
    tag instead:
    \code
    Product {
        type: "loadablemodule"
        // ...
        Group {
            fileTagsFilter: cpp.separateDebugInformation ? ["debuginfo_loadablemodule"] : []
            qbs.install: true
            qbs.installDir: "PlugIns"
            qbs.installSourceBase: buildDirectory
        }
    }
    \endcode

    \section1 How do I use precompiled headers?

    If you use a \l Group item to add a precompiled header file to a product
    and mark it with the \l{filetags-cpp}{relevant file tag} (\c c_pch_src,
    \c cpp_pch_src, \c objc_pch_src, or \c objcpp_pch_src), it is used
    automatically.

    Only one precompiled header is allowed per product and language.

    For example:

    \code
    CppApplication {
        name: "the-app"
        files: ["main.cpp"]

        Group {
            files: ["precompiled-header.pch"]
            fileTags: ["cpp_pch_src"]
        }
    }
    \endcode

    \section1 How do I make use of rpaths?

    rpath designates the run-time search path used by the dynamic linker when loading
    libraries on UNIX platforms. This concept does not apply to Windows.

    Suppose you have a project with two dynamic library products \c LibraryA and \c LibraryB
    and one dependent application product. Also, \c LibraryB depends on \c LibraryA. The
    application is installed to the \c bin folder and the libraries are installed to the
    \c lib folder next to the \c bin folder. You want the application to be able to find the
    dependent libraries relative to its own location. This can be achieved by usage of the
    \l{cpp::rpaths}{cpp.rpaths} property.

    First, you need to set \l{cpp::rpaths}{cpp.rpaths} in your libraries so they can
    find dependent libraries in the same folder where they are located. This can be
    done as follows:

    \snippet ../examples/rpaths/rpaths.qbs 0

    We are setting \l{cpp::rpaths}{cpp.rpaths} to \l{cpp::rpathOrigin}{cpp.rpathOrigin} which
    expands to \c "$ORIGIN" on Linux and to \c "@loader_path" on macOS.

    On macOS you also need to set \l{cpp::sonamePrefix}{cpp.sonamePrefix} to \c "@rpath" to
    tell the dynamic linker to use RPATHs when loading this library.

    \c LibraryB looks exactly the same:

    \snippet ../examples/rpaths/rpaths.qbs 1

    In a real project, it might be a good idea to move common properties to some base item
    and inherit it in library items.

    The application item is a bit different. It sets \l{cpp::rpaths}{cpp.rpaths} to the
    \c "lib" folder which is located one level up from the \c bin folder:

    \snippet ../examples/rpaths/rpaths.qbs 2

    \section1 How do I make sure my generated sources are getting compiled?

    The rules in a \QBS project do not care whether its inputs are actual source files
    listed on the right-hand side of a \l{Product::files}{files} property or artifacts
    that were generated by another rule. For instance, the C++ compiler rule considers
    all input files of type "cpp", no matter how they got into the product. The following
    example project demonstrates this. One of its source files exists in the repository,
    the other one is generated at build time. Both are getting compiled the same way.
    \note Do not try to add the generated files to a \c files property. Declaring them
    as rule outputs is all that is needed to make \QBS know about them.
    \code
    import qbs.TextFile
    CppApplication {
        files: ["impl.cpp", "impl.h"]
        cpp.includePaths: sourceDirectory
        Rule {
            multiplex: true
            Artifact { filePath: "main.cpp"; fileTags: "cpp" }
            prepare: {
                var cmd = new JavaScriptCommand();
                cmd.description = "generating " + output.fileName;
                cmd.sourceCode = function() {
                    var f = new TextFile(output.filePath, TextFile.WriteOnly);
                    f.writeLine("#include <impl.h>");
                    f.writeLine("int main()");
                    f.writeLine("{");
                    f.writeLine("    return functionFromImpl();");
                    f.writeLine("}");
                    f.close();
                };
                return cmd;
            }
        }
    }
    \endcode

    \section1 How do I run my autotests?

    There are two simple things you need to do in your project. Firstly, you
    mark your test executables as such. This is done by adding the tag \c{"autotest"}
    to the product type:
    \code
    CppApplication {
        name: "test1"
        type: base.concat("autotest")
        // ...
    }
    \endcode
    The second step is to instantiate an \l AutotestRunner product in your project:
    \code
    Project {
        // ...
        AutotestRunner { name: "run_my_tests" }
    }
    \endcode
    Building an AutotestRunner product does not produce artifacts, but triggers execution of all
    applications whose products are tagged as autotests:
    \code
    $ qbs -p run_my_tests
    test1: PASS
    test2: PASS
    test3: FAIL
    ...
    \endcode
    See the \l{AutotestRunner}{AutotestRunner documentation} for how to fine-tune the behavior.

    \section1 How do I use ccache?

    \l ccache is a popular C/C++ compiler cache on Unix to speed up compiling the
    same content multiple times.

    \QBS excels at tracking dependencies and avoiding needless recompilations, so
    for linear development of one project and configuration using ccache
    has little benefit. But if you switch between revisions of a project,
    or build the same project with different configurations, a global cache like
    ccache can speed up compilations significantly.

    ccache can be used by setting up symbolic links to compiler executables
    (such as \c g++, \c gcc) in the file system. In this setup, the use of ccache is
    transparent to \QBS. If you prefer to call ccache explicitly, you should
    set \l{cpp::compilerWrapper}{cpp.compilerWrapper} to \c ccache.

    \note Using precompiled headers might prevent ccache from actually
    using cached results. To work around this, you can set
    \c{sloppiness=pch_defines,time_macros} in your local ccache options.
    See the \l{ccache documentation about precompiled headers} for further details.

    \section1 How do I create a module for a third-party library?

    If you have pre-built binary files in your source tree, you can create
    modules for them and then introduce dependencies between your project and
    the modules to pull in the functionality of a third-party library.

    Create the following folder structure to store the module files:

    \code
    $projectroot/modules/ThirdParty
    \endcode

    Then create a file in the directory that specifies the module properties
    for each supported toolchain. The filename must have the \c .qbs extension.
    The module will be pulled in if a product declares a dependency on it.

    In the following example, \c lib1.dylib is a multi-architecture library
    containing both 32-bit and 64-bit code.

    \code
    ---ThirdParty.qbs---

    Module {
        Depends { name: "cpp" }
        cpp.includePaths: ["/somewhere/include"]
        Properties {
            condition: qbs.targetOS.contains("android")
            cpp.dynamicLibraries: ["/somewhere/android/" + Android.ndk.abi + "/lib1.so"]
        }
        Properties {
            condition: qbs.targetOS.contains("macos")
            cpp.dynamicLibraries: ["/somewhere/macos/lib1.dylib"]
        }
        Properties {
            condition: qbs.targetOS.contains("windows") && qbs.architecture === "x86"
            cpp.dynamicLibraries: ["/somewhere/windows_x86/lib1.lib"]
        }
        Properties {
            condition: qbs.targetOS.contains("windows") && qbs.architecture === "x86_64"
            cpp.dynamicLibraries: ["/somewhere/windows_x86_64/lib1.lib"]
        }
    }
    \endcode

    Finally, declare dependencies on \c ThirdParty in your project:

    \code
    CppApplication {
        name: "the-app"
        files: ["main.cpp"]
        Depends { name: "ThirdParty" }
    }
    \endcode

    \section1 How do I create application bundles and frameworks on iOS, macOS, tvOS, and watchOS?

    Creating an application bundle or framework is achieved by introducing a
    dependency on the \l{bundle} module and setting the \l{bundle::isBundle}
    {bundle.isBundle} property to \c true.

    Here is a simple example for an application:

    \code
    Application {
        Depends { name: "cpp" }
        Depends { name: "bundle" }
        bundle.isBundle: true
        name: "the-app"
        files: ["main.cpp"]
    }
    \endcode

    and for a framework:

    \code
    DynamicLibrary {
        Depends { name: "cpp" }
        Depends { name: "bundle" }
        bundle.isBundle: true
        name: "the-lib"
        files: ["lib.cpp", "lib.h"]
    }
    \endcode

    \QBS also supports building static frameworks. You can create one by
    replacing the \l{DynamicLibrary} item with a \l{StaticLibrary} item in the
    example above.

    \note When using the \l{Application} item (or convenience items, such as
    \l{CppApplication}, \l{DynamicLibrary}, and \l{StaticLibrary}), your
    products will be built as bundles on Apple platforms by default (this
    behavior is subject to change in a future release).

    To explicitly control whether your product is built as a bundle, set the \c bundle.isBundle
    property. Setting the \l{Product::}{consoleApplication} property of your
    product will also influence whether your product is built as a bundle.

    Building your application against your framework is the same as linking a normal dynamic or
    static library; see the \l{How do I make my app build against my library?} section for an
    example.

    \section1 How do I build against libraries that provide pkg-config files?

    Just add a \l Depends item that matches the name of the pkg-config module, and \QBS
    will automatically employ \l{https://www.freedesktop.org/wiki/Software/pkg-config}{pkg-config}
    to find the headers and libraries if no matching \QBS module can be found. For instance,
    to build against the OpenSSL library, you would write this:
    \code
    Depends { name: "openssl" }
    \endcode
    That's it. The pkg-config behavior can be fine-tuned via the \l pkgconfig module,
    but normally you will not need to pull it in explicitly.

    Internally, this functionality is implemented via \l {Module Providers}

    \section1 How do I apply C/C++ preprocessor macros to only a subset of the files in my product?

    Use a \l{Group} item to define a subset of project files. To add
    macros within the group, you need to use the \c outer.concat property,
    because you are adding macros to those specified in the outer scope.

    In the following example, \c MACRO_EVERYWHERE is defined for all files in
    the \l{Product} unless a Group overrides the macro, whereas
    \c MACRO_GROUP is only defined for \c groupFile.cpp.

    \code
    Product {
        Depends { name: "cpp" }
        cpp.defines: ["MACRO_EVERYWHERE"]
        Group {
            cpp.defines: outer.concat("MACRO_GROUP")
            files: "groupFile.cpp"
        }
    }
    \endcode

    The \c cpp.defines statements inside a \c Group only apply to the files in
    that \c Group, and therefore you cannot use a \c Group to include a bunch of
    files and globally visible macros. The macros must be specified in a
    \l{Properties} item at the same level as the \c Group if
    they need to be visible to files outside the \c Group:

    \code
    Product {
        Depends { name: "cpp" }
        Group {
            condition: project.supportMyFeature
            files: "myFile.cpp"
        }

        property stringList commonDefines: ["ONE", "TWO"]

        Properties {
            condition: project.supportMyFeature
            cpp.defines: commonDefines.concat("MYFEATURE_SUPPORTED")
        }
    }
    \endcode

    \section1 How do I disable a compiler warning?

    You can use the \l {cpp::commonCompilerFlags}{cpp.commonCompilerFlags} property
    to pass flags to the compiler. For example, to disable deprecation warnings:

    \code
    CppApplication {
        // ...

        readonly property bool isMsvc: qbs.toolchain.contains("msvc")

        cpp.commonCompilerFlags: isMsvc ? "/wd4996" : "-Wno-deprecated-declarations"
    }
    \endcode

    It is also possible to disable all warnings at once by setting the
    \l {cpp::commonCompilerFlags}{cpp.warningLevel} property to \c "none".
    Usually this approach is discouraged, but it can be useful in some cases,
    such as when compiling third party code:

    \code
    Group {
        cpp.warningLevel: "none"

        files: [
            "3rdparty.h",
            "3rdparty.cpp"
        ]
    }
    \endcode

    \section1 How do I make the state of my Git repository available to my source files?

    Add a dependency to the \l{vcs} module to your product:
    \code
    CppApplication {
        // ...
        Depends { name: "vcs" }
        // ...
    }
    \endcode
    Your source files will now have access to a macro whose value is a string representing the
    current Git or Subversion HEAD:
    \code
    #include <vcs-repo-state.h>
    #include <iostream>

    int main()
    {
        std::cout << "I was built from " << VCS_REPO_STATE << std::endl;
    }
    \endcode

    This value is also available via the \l{vcs::repoState}{vcs.repoState}
    property.

    \section1 How do I limit the number of concurrent jobs for the linker only?
    \target job-pool-howto

    While it is usually desirable to run as many compiler jobs as there are CPU cores,
    the same is not true for linker jobs. The reason is that linkers are typically
    I/O bound rather than CPU bound. When building large libraries, they also tend
    to use up enormous amounts of memory. Therefore, we'd like to make sure that
    only a few linkers are running at the same time without limiting other types
    of jobs. In \QBS, this is achieved via \e{job pools}. There are several ways
    to make use of them.

    Firstly, you can provide a limit via the command line:
    \code
    $ qbs --job-limits linker:4
    \endcode
    The above call instructs \QBS to run at most four linker instances at the same
    time, while leaving the general number of concurrent jobs at the default
    value, which is derived from the number of CPU cores.
    The \c linker string on the command line refers to the job pool of the same
    name, which the \l{cpp-job-pools}{cpp module} assigns to all its commands that
    invoke a linker.

    Secondly, you can set a limit via the settings, either generally
    or for a specific profile:
    \code
    $ qbs config preferences.jobLimit.linker 4
    $ qbs config profiles.myprofile.preferences.jobLimit.linker 2
    \endcode

    And finally, you can also set the limit per project or per product, using a
    \l JobLimit item:
    \code
    Product {
        name: "my_huge_library"
        JobLimit {
            jobPool: "linker"
            jobCount: 1
        }
        // ...
    }
    \endcode
    The above construct ensures that this specific library is never linked at
    the same time as any other binary in the project.

    Job limits set on the command line override those from the settings, which in turn
    override the ones defined within a project. Use the \c{--enforce-project-job-limits}
    option to give the job limits defined via \c JobLimit items maximum precedence.

    \section1 How do I add QML files to a project?

    The simplest way to add QML files to a project is to add them to a
    \l {https://doc.qt.io/qt/resources.html}{Qt resource file}:

    \code
    QtGuiApplication {
        // ...

        files: "main.cpp"

        Group {
            prefix: "qml/"
            files: ["main.qml", "HomePage.qml"]
            fileTags: ["qt.qml.qml", "qt.core.resource_data"]
        }
    }
    \endcode

    In the example above, we declare each QML file as having the
    \l {filetags-qtcore}{"qt.core.resource_data"} file tag. This ensures
    that it is added to a generated resource file.

    \section1 How do I define a reusable Group of files that can be included in other \QBS files?

    Suppose you have an application and tests for that application, and that
    the project is structured in the following way:

    \badcode
    ├── app
    │   ├── app.qbs
    │   ├── ...
    │   └── qml
    │       └── ui
    │           ├── AboutPopup.qml
    │           └── ...
    ├── my-project.qbs
    └── tests
        ├── tst_app.cpp
        ├── ...
        └── tests.qbs
    \endcode

    Both projects need access to the QML files used by the
    application. To demonstrate how this can be done, we'll create a file
    named \c qml-ui.qbs and put it in the \c app/qml/ui directory:

    \code
    Group {
        prefix: path + "/"
        fileTags: ["qt.qml.qml", "qt.core.resource_data"]
        files: [
            "AboutPopup.qml",
            // ...
        ]
    }
    \endcode

    This Group is a variation of the one in the
    \l {How do I add QML files to a project?}{section above}.

    If no prefix is specified, the file names listed in the \c files property
    are resolved relative to the \e importing product's (e.g. \c app.qbs)
    directory. For that reason, we set the prefix to inform \QBS that the file
    names should be resolved relative to the \e imported item instead:
    \c qml-ui.qbs. Conveniently, this also means that we don't need to specify
    the path prefix for each file.

    The application can then import the file like so:

    \code
    import "qml/ui/qml-ui.qbs" as QmlUiFiles

    QtGuiApplication {
        // ...

        files: "main.cpp"

        QmlUiFiles {}
    }
    \endcode

    The tests can use a relative path to import the file:

    \code
    import "../app/qml/ui/qml-ui.qbs" as QmlUiFiles

    QtGuiApplication {
        // ...

        files: "tst_app.cpp"

        QmlUiFiles {}
    }
    \endcode

    \section1 How do I print the value of a property?

    Use the \l {Console API}{console API}. For example, suppose your project
    is not built the way you expect it to be, and you suspect that
    \c qbs.targetOS has the wrong value:

    \code
    readonly property bool unix: qbs.targetOS.contains("unix")
    \endcode

    To find out the value of \c qbs.targetOS, use \c {console.info()}:

    \code
    readonly property bool unix: {
        console.info("qbs.targetOS: " + qbs.targetOS)
        return qbs.targetOS.contains("unix")
    }
    \endcode

    It is also possible to throw an exception with the text saying what is wrong - this might
    be useful if the property contains invalid or unsupported value:
    \code
    readonly property bool unix: {
        if (qbs.targetOS.contains("darwin"))
            throw "Apple platforms are not supported";
        return qbs.targetOS.contains("unix")
    }
    \endcode

    \section1 How do I debug \QBS scripts?

    To debug the value of a specific property, see the \l{How do I print the value of a property}
    section.

    Similar debugging techniques could be used within \l{Rule}{Rules} or \c .js files.

    It is also possible to increase \QBS' logging level using the \c --more-verbose (\c -v) option
    of the \c{qbs build} command:

    \code
    qbs build -v config:release
    \endcode

    \QBS uses the Qt Categorized Logging system which allows to configure logging categories
    in \l{https://doc.qt.io/qt-5/qloggingcategory.html#configuring-categories}{multiple ways}. For
    example, to enable debug logging for the \c moduleloader category, use the following command:
    \code
    QT_LOGGING_RULES="qbs.moduleloader.debug=true" qbs resolve
    \endcode

    To list all the files in the project directory and show whether they are known to qbs in the
    respective configuration, use the \c{qbs status} command:
    \code
    qbs status config:release
    \endcode

    \section1 How do I sign an application for an Apple platform?

    To sign an application for an Apple platform, you need to use the \l{codesign} module.

    \code
        Depends { name: "codesign" }
    \endcode

    Several properties should be set to do signing as shown below.

    Make sure that bundle and team indentifiers match the one used for signing:

    \code
        bundle.identifierPrefix: "com.johndoe"
        codesign.teamIdentifier: "John Doe"
    \endcode

    It is also possible to use an ID of the team identifier instead of a name:
    \code
        codesign.teamIdentifier: "1234ABCDEF"
    \endcode

    \QBS will then try to find the matching signing identity and provisioning profile based on
    \l{codesign::signingType}{codesign.signingType}.

    It is also possible to specify \l{codesign::signingIdentity}{codesign.signingIdentity}
    manually:

    \code
        codesign.signingIdentity: "Apple Development: johndoe@apple.com (ABCDEF1234)"
    \endcode

    It is also possible to use an ID of the signing identity instead of a name:
    \code
        codesign.signingIdentity: "ABCDEF1234567890ABCDEF1234567890ABCDEF12"
    \endcode

    If \QBS cannot find the suitable provisioning profile, you can specify it manually as well:
    \code
        codesign.provisioningProfile: "abcdef12-1234-5678-1111-abcdef123456"
    \endcode
*/