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.
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)
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.
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');
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.
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'... |
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... |
For more information, see packNGo
in Build Information Methods.
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
folder
treematlabroot
sDirFiles.zip
— files in
and under your build folder where you initiated code generation
otherFiles.zip
— required
files not in the
or matlabroot
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.