This toolbox provides tools to create a sandbox for developing custom MATLAB toolbox. It uses a convention enforcing best practices in order to help streamline and standardise your toolbox development and packaging process.
This version is for MATLAB release R2016b onwards.
A few other notes while I'm working on updating a release script generated by toolbox tools
* The release script asserts that the Matlab version is greater than 9.1 and then later it has code that checks if the release is less than 9.0. it seems that the second code can never be reached.
* I setup the release script to create a directory for each release so the documentation and other materials can be included along with the release
* I did manage to get the release script to also release a standalone executable of an application by using the mcc command.
* I changed the way you handle the current directory to minimize the changes in the current directory and make it less reliant on the current directory.
Why does the release script have the name of the toolbox as an input? The release script seems to be written so it needs to be customized for that specific toolbox.
I changed the input to a version number which is used to check that the version listed in the toolbox package matches the version I intended to release.
Many thanks for spotting that. The 'today' function does have a dependency on the Financial Toolbox, and I'll be updating the toolbox code shortly.
You can indeed package a standalone application using the same workflow or setup. In that case, you will have a MATLAB Compiler project file sitting in the same directory as your toolbox project file. Using the release.m script, you can automatically create a new version of the standalone application when you package a new version of the toolbox.
Thanks for the response and great suggestion about packaging apps!
I noticed that on line 82 of mksandbox.m you have the following code: "datestr(today)"
Every time I run the "mksandbox" function I get a warning that contents.m could not be written and if I try that bit of code I get a warning that today is only available with the Financial Toolbox. I don't think you meant to have that dependency. You might be able to use the "date" or "now" functions instead to avoid this dependency.
Have you included the compiling of applications in this flow using MATLAB compiler? It seems like it could be part of the flow similar to the packaging of apps so the compiled version is also released at the same time as the toolbox. Just with the output going to a separate location to be distributed separately. Just thought I would check to see if you have experience doing this before adding this customization.
Thanks for your comment. I’ll be talking about best practices on packaging MATLAB apps within a toolbox in an upcoming post on Developer Zone, so stay tuned! But essentially you want to avoid files being duplicated or packaged more than once in the toolbox(.mltbx) and app(.mlappinstall) files. My suggestion is to only package the app launcher or main file in the mlappinstall file. All other code and dependencies are packaged in the mltbx file. This is particularly relevant if you have more than one app that shares the same toolbox code.
Users can only install and access content of an mltbx file from within MATLAB. Standalone applications will have to be packaged and distributed separately to users who do not have access to MATLAB.
What are the best practices for including packaged apps and compiled applications in this workflow? These apps and compiled applications would be based on the code in the toolbox. The apps would need to be included as a part of the toolbox. The compiled applications would be used for users without access (or willingness to learn) Matlab.
Updated mksandbox.m and example release script.
Updated help files.