# mkapp

Source: [https://docs.qualcomm.com/doc/80-41102-4/topic/mkapp.html](https://docs.qualcomm.com/doc/80-41102-4/topic/mkapp.html)

`mkapp` can be used to [build a binary app package (.app file)](https://docs.qualcomm.com/doc/80-41102-4/topic/mkapp.html#concept.dita_a679808e-b4ba-4e44-b3b0-ffd85fbb4420__section_g1f_22z_rvb) that can be later built into a larger system of interworking apps using [mksys](https://docs.qualcomm.com/doc/80-41102-4/topic/mksys.html). You might want to use `mkapp` in this way if you want to provide an app to someone but you can't share your app's source code with them for whatever reason.

`mkapp` can also be used with some target devices (e.g., Linux-based targets) to [Building an App Bundle](https://docs.qualcomm.com/doc/80-41102-4/topic/mkapp.html#concept.dita_a679808e-b4ba-4e44-b3b0-ffd85fbb4420__section_h1f_22z_rvb), producing an update pack that can be used to install just that one app onto the target, without touching any of the other apps that are already running on the target device. It is recommended that you do not do things this way, though. Building complete systems of interworking apps using [mksys](https://docs.qualcomm.com/doc/80-41102-4/topic/mksys.html) is the preferred approach.

The main input for `mkapp` is an [Application Definition .adef](https://docs.qualcomm.com/bundle/resource/topics/80-41102-3_21528/def_files_adef.html) file that contains these definitions:
      
- executables to build when the app is built
- components and/or other files to build into those executables
- other files to be included as a part of the app
- if the app will run in a sandbox, files to access outside the sandbox
- executables to run when the app is started
- command-line arguments and environment variables to pass to those apps
- limits to place on the app (CPU, memory, etc.)

`mkapp` will parse the .adef file, determine which components, interface definitions, and other source files are needed, build those into the libraries and executables required, generate the on-target configuration data needed, and add everything to an app bundle.

See [Application Definition .adef](https://docs.qualcomm.com/bundle/resource/topics/80-41102-3_21528/def_files_adef.html) for details on app def files.

See [Definition Files](https://docs.qualcomm.com/bundle/resource/topics/80-41102-3_21528/def_files.html) for more info on TelAF definition files, in general.

See [Tool Chain Configuration](https://docs.qualcomm.com/doc/80-41102-4/topic/mk-Tools.html#concept.dita_9bcf13bd-17cd-4a87-ac7c-dcbd92c5bded__section_yw2_fcz_rvb) for information on how `mkapp` decides what compilers, etc. to use.

## Building a Binary App Package

There may be occasions when you want or need to distribute an app for inclusion in another user's system, but you cannot distribute the source code for this app. In that case you can use `mkapp` with the `-b` (or `--bin-pack`) option. For example, building a simple `helloWorld` style app:

    $ mkapp -t sa515m helloWorld.adef -bCopy to clipboard

This will produce a file called `helloWorld.sa515m.app` which is a binary app package ready for distribution to others for inclusion in their system builds. To use this binary app package, simply include it in the `apps` section of your system's .sdef file, like you would with a .adef file:

    apps:
    {
        helloWorld.sa515m.app
    }Copy to clipboard

Note that this binary app package is compiled specifically for the given target, so an app compiled for one target is not necessarily compatible with another target.

## Building an App Bundle

`mkapp` can be used to generate an app bundle (also known as an update pack [.update] file) to install and run on a target device.

App bundles (.update files) are compressed archives that can be used to:
- Install your app on a target.
- Update your app to a new version.

But, use of [mksys](https://docs.qualcomm.com/doc/80-41102-4/topic/mksys.html) is preferred over using `mkapp` in this way. [mksys](https://docs.qualcomm.com/doc/80-41102-4/topic/mksys.html)produces a full system bundle which has the following benefits:
- limits the risk of leaving your target in a bad state
- performs some inter-app consistency checks (e.g., checks for typos in bindings)
- ensures that all apps are updated together
- reduces the chances of an app hanging at start-up because of missing or misspelled bindings

## Usage

`mkapp` provides flags to set the target, set build options, and specify additional search directories:

    Command line parameters
      -C, --cflags, <string>
            (Multiple, optional) Specify extra flags to be passed to the C compiler.
    
      -L, --ldflags, <string>
            (Multiple, optional) Specify extra flags to be passed to the linker when linking executables.
    
      -X, --cxxflags, <string>
            (Multiple, optional) Specify extra flags to be passed to the C++ compiler.
    
      -a, --append-to-version, <string>
            (Multiple, optional) Specify a suffix to append to the application version specified in the
            .adef file.  Will automatically insert a '.' between the .adef's version string and any
            version strings specified on the command-line.  Multiple occurrences of this argument will
            be combined into a single string.
    
      -b, --bin-pack
            (Optional) Generate a binary-app package instead of a .update file. Binary-app packages can
            be used to distribute an application without its original source code.  This binary app
            package file is intended to be included in a system definition (.sdef)  file's 'apps:'
            section in place of a .adef file.
    
      -c, --component-search, <string>
            (Multiple, optional) (DEPRECATED) Add a directory to the source search path (same as -s).
    
      -d, --debug-dir, <string>
            (Optional) Generate debug symbols and place them in the specified directory.  Debug symbol
            files will be named with build-id
    
      -g, --generate-code
            (Optional) Only generate code, but don't compile, link, or bundle anything. The interface
            definition (include) files will be generated, along with component and executable main files
            and configuration files. This is useful for supporting context-sensitive auto-complete and
            related features in source code editors, for example.
    
      -i, --interface-search, <string>
            (Multiple, optional) Add a directory to the interface search path.
    
      -n, --dont-run-ninja
            (Optional) Even if a build.ninja file exists, ignore it, delete the staging area, parse all
            inputs, and generate all output files, including a new copy of the build.ninja, then exit
            without running ninja.  This is used by the build.ninja to to regenerate itself and any
            other files that need to be regenerated when the build.ninja finds itself out of date.
    
      -o, --output-dir, <string>
            (Optional) Specify the directory into which the final, built application file (ready to be
            installed on the target) should be put.
    
      -s, --source-search, <string>
            (Multiple, optional) Add a directory to the source search path.
    
      -t, --target, <string>
            (Optional) Set the compile target (sa515m).
    
      -v, --verbose
            (Optional) Set into verbose mode for extra diagnostic information.
    
      -w, --object-dir, <string>
            (Optional) Specify the directory into which any intermediate build artifacts (such as .o
            files and generated source code files) should be put.Copy to clipboard

**Parent Topic:** [mk Tools](https://docs.qualcomm.com/doc/80-41102-4/topic/mk-Tools.html)

Last Published: Jan 13, 2025

[Previous Topic
mk Tools](https://docs.qualcomm.com/bundle/publicresource/80-41102-4/topics/mk-Tools.md) [Next Topic
mkexe](https://docs.qualcomm.com/bundle/publicresource/80-41102-4/topics/mkexe.md)