Package Code for Other Development Environments

When to Package Code

To relocate the generated code files to another development environment, such as a system or an integrated development environment (IDE) that does not include MATLAB^®, use the packNGo function at the command line or the Package option in the MATLAB Coder™ app. The files are packaged in a compressed file that you can relocate and unpack using a standard zip utility.

See Package Generated Code Using the MATLAB Coder App and Package Generated Code at the Command Line.

Package Generated Code Using the MATLAB Coder App

This example shows how to package generated code into a zip file for relocation using the Package option in the MATLAB Coder app. By default, MATLAB Coder creates the zip file in the current working folder.

In a local writable folder, for example c:\work, write a function foo that takes two double inputs.
```
function y = foo(A,B)
  y = A + B;
end
```
Open the MATLAB Coder app. On the MATLAB Toolstrip Apps tab, under Code Generation, click the MATLAB Coder app icon.
On the Select Source Files page, enter the name of the entry-point function foo. Click Next to go to the Define Input Types page.
Specify that inputs A and B are scalar doubles. Click Next to go to the Check for Run-Time Issues page.
Check for run-time issues. In the Check for Run-Time Issues dialog box, enter code that calls foo with scalar double inputs. For example:
```
foo(1,2)
```
Click Check for Issues.
To check for run-time issues, the app generates and runs a MEX function. The app does not find issues for foo. Click Next to go to the Generate Code page.
In the Generate dialog box, set the Build Type to Source Code, Static Library, Dynamic Library, or Executable. You cannot package the code generated for MEX targets.
Click Generate. Click Next to go to the Finish Workflow page.
On the Finish Workflow page, click Package.
In the Package dialog box, specify the package file name and packaging type. By default, the app derives the name of the package file from the project name. The app saves the file in the current working folder. By default, the app packages the generated files as a single, flat folder. For this example, use the default values, and then click Save.
This zip file contains the C code and header files required for relocation. It does not contain:
- Compile flags
- Defines
- Makefiles
- Example main files, unless you configure code generation to generate and compile the example main function. See Incorporate Generated Code Using an Example Main Function.
Inspect the contents of foo_pkg.zip in your working folder to verify that it is ready for relocation to the destination system. Depending on the zip tool that you use, you can potentially open and inspect the file without unpacking it.
You can now relocate the resulting zip file to the desired development environment and unpack the file.

Package Generated Code at the Command Line

This example shows how to package generated code into a zip file for relocation using the packNGo function at the command line.

In a local writable folder, for example c:\work, write a function foo that takes two double inputs.
```
function y = foo(A,B)
  y = A + B;
end
```
Generate a static library for function foo. (packNGo does not package MEX function code.)
```
codegen -report -config:lib foo -args {0,0}
```
codegen generates code in the c:\work\codegen\lib\foo folder.

Load the buildInfo object.

load('c:\work\codegen\lib\foo\buildInfo.mat')

Create the zip file.
```
packNGo(buildInfo, 'fileName', 'foo.zip');
```
Alternatively, use the notation:
```
buildInfo.packNGo('fileName', 'foo.zip');
```
The packNGo function creates a zip file, foo.zip, in the current working folder. This zip file contains the C code and header files required for relocation. It does not contain:
- Compile flags
- Defines
- Makefiles
- Example main files, unless you configure code generation to generate and compile the example main function. See Incorporate Generated Code Using an Example Main Function.
In this example, you specify only the file name. Optionally, you can specify additional packaging options. See Specify packNGo Options.
Inspect the contents of foo.zip to verify that it is ready for relocation to the destination system. Depending on the zip tool that you use, you can potentially open and inspect the file without unpacking it. If you need to unpack the file and you packaged the generated code files as a hierarchical structure, you will need to unpack the primary and secondary zip files. When you unpack the secondary zip files, relative paths of the files are preserved.

You can now relocate the resulting zip file to the desired development environment and unpack the file.

Specify packNGo Options

You can specify options for the packNGo function.

To	Specify
Change the structure of the file packaging to hierarchical	`packNGo(buildInfo, 'packType' 'hierarchical');`
Change the structure of the file packaging to hierarchical and rename the primary zip file	`packNGo(buildInfo, 'packType' 'hierarchical'... 'fileName' 'zippedsrcs');`
Include all header files found on the include path in the zip file (rather than the minimal header files required to build the code)	`packNGo(buildInfo, 'minimalHeaders' false);`
Generate warnings for parse errors and missing files	`packNGo(buildInfo, 'ignoreParseError' true... 'ignoreFileMissing' true);`

For more information, see packNGo.

Choose a Structure for the Zip File

Before you generate and package the files, decide whether you want to package the files in a flat or hierarchical folder structure. By default, the packNGo function packages the files in a single, flat folder structure. This approach is the simplest and might be the optimal choice.

If	Use
You are relocating files to an IDE that does not use the generated makefile, or the code is not dependent on the relative location of required static files	A single, flat folder structure
The target development environment must maintain the folder structure of the source environment because it uses the generated makefile, or the code is dependent on the relative location of files	A hierarchical structure

If you use a hierarchical structure, the packNGo function creates two levels of zip files. There is a primary zip file, which in turn contains the following secondary zip files:

mlrFiles.zip — files in your matlabroot folder tree
sDirFiles.zip — files in and under your build folder where you initiated code generation
otherFiles.zip — required files not in the matlabroot or start folder trees

Paths for the secondary zip files are relative to the root folder of the primary zip file, maintaining the source development folder structure.