{"id":2835,"date":"2022-10-17T12:34:02","date_gmt":"2022-10-17T16:34:02","guid":{"rendered":"https:\/\/blogs.mathworks.com\/developer\/?p=2835"},"modified":"2022-10-17T14:22:34","modified_gmt":"2022-10-17T18:22:34","slug":"building-blocks-with-buildtool","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/developer\/2022\/10\/17\/building-blocks-with-buildtool\/","title":{"rendered":"Building Blocks"},"content":{"rendered":"\r\n\r\n

My people! Oh how I have missed you. It has been such a long time since we have talked about some developer workflow goodness here on the blog. I have found it hard to sit down and write up more thoughts and musings on these topics, but the silver lining here is a big reason for my lack of time is that we have been hard at work delivering development infrastructure for MATLAB.<\/p>

One of those things is the new build tool for MATLAB that included in R2022b! We are super excited about this tool's rookie release, but even more excited for all the value that will come of it as you begin using it for your MATLAB projects.<\/p>

What is this thing anyway? Well in short it is a standard interface for you to build and collaborate on your MATLAB projects. \"Build?\", you say?<\/p>

Yes, \"Build!\", I say. Anyone developing serious, shareable, production grade MATLAB code knows that even though MATLAB is an \"easy-to-leverage\" language that typically doesn't require an actual \"compile\" step, it still requires a development process that includes tasks like testing, quality gates, and bumping a release number. Also it turns out that there are many ways in which MATLAB does indeed build<\/b><\/i> something. Think mex files, p-code, code generation, toolbox packages, doc pages, or producing artifacts from MATLAB Compiler and Compiler SDK. These are all build steps.<\/p>

The issue though, has been that there has been no standard API for MATLAB projects to organize these build steps. It usually ends up looking something like this:<\/p>

\"\" <\/p>

Does this look familiar? It does to me. All of these scripts grow in a project or repo for doing these specific tasks. Each one looks a little different because one was written on Tuesday and the other the following Monday. If we are lucky, we remember how these all work when we need to interact with them. However, sometimes we are not lucky. Sometimes we go back to our code and haven't the foggiest idea how we built it, in what order, and with which scripts.<\/p>

Also, know who is never<\/i> so lucky? A new contributor. Someone who wants to contribute to your code and hasn't learned the system you have put in place to develop the project. Some projects are rigorous and do indeed have their own custom-authored build framework put in place. This is great for them, but requires more maintenance, and even in these cases a new developer on the project needs to learn this custom system, which is different than all the other systems to build MATLAB code.<\/p>

Well, not anymore. Starting in R2022b we now have a standard interface and build framework<\/a> that enables project owners to easily produce their build in a way that anyone else can consume, no matter how complicated the build pipeline is. We now can move from ad-hoc scripts and custom build systems to a known, structured, and standard framework.<\/p>

\"\" <\/p>

Let's take my favorite simple Mass-Spring-Damper example (looks like I am still a mechanical engineer at heart). This is a simple example \"toolbox\" that has 3 components, a design script springMassDamperDesign.m<\/tt><\/b> that defines stiffness and damping constants for the system, a function simulateSystem.m<\/tt><\/b> that simulates the system from an initial condition outside of equilibrium to show a step response, and a mex file convec.c<\/tt><\/b> that convolves two arrays, which might be a useful utility for a dynamic system such as this. It also has a couple tests to ensure all is well and good as the code changes.<\/p>

\"\" <\/p>

Hopefully the author of this code knows all about these components and why they were written as they were. However, if I am a contributor for the first time to this code base I have no idea. My workflow might look something like this:<\/p>

  1. Get the code<\/li>
  2. Use the toolbox<\/li>
  3. See there is something I want to change about the toolbox, a feature to add or a tweak to the design<\/li>
  4. Make the change<\/li>
  5. Submit the change for the win!!<\/li><\/ol><\/div>

    Seems like I am setting myself up for a solid contribution, and I am very proud of myself. After getting the code I see the initial design looks like so:<\/p>

    \r\nfunction<\/span> design = springMassDamperDesign(mass)\r\n\r\nif<\/span> nargin\r\n  m = mass;\r\nelse<\/span>\r\n  m = 1500; % Need to know the mass to determine critical damping<\/span>\r\nend<\/span>\r\n\r\ndesign.k = 5e6; % Spring Constant<\/span>\r\ndesign.c = 5e5; % Damping coefficient<\/span>\r\n\r\n\r\n<\/pre>
    ...and when simulating using the included function:<\/p>
    \r\nfunction<\/span> [x, t] = simulateSystem(design)\r\n\r\nif<\/span> ~isstruct(design) || ~all(isfield(design,{'c'<\/span>,'k'<\/span>}))\r\n    error('simulateSystem:InvalidDesign:ShouldBeStruct'<\/span>, ...<\/span>\r\n        'The design should be a structure with fields \"c\" and \"k\"'<\/span>);\r\nend<\/span>\r\n\r\n% Design variables<\/span>\r\nc = design.c;\r\nk = design.k;\r\n\r\n% Constant variables<\/span>\r\nz0 = [-0.1; 0];  % Initial Position and Velocity<\/span>\r\nm = 1500;        % Mass<\/span>\r\n\r\nodefun = @(t,z) [0 1; -k\/m -c\/m]*z;\r\n[t, z] = ode45(odefun, [0, 1], z0);\r\n\r\n% The first column is the position (displacement from equilibrium)<\/span>\r\nx = z(:, 1);\r\n\r\n<\/pre>
    ...it yields the following response:<\/p>
    [t,y] = simulateSystem(springMassDamperDesign);\r\nplot(y,t)\r\n<\/pre>\"\" 
    Pretty decent, but I think that there is room for improvement. I think we can get back to equilibrium sooner, and I like a nice smooth shift that slightly overshoots. Because I am an excellent mechanical engineer, this is a clearly preferable design, we just need to have a little less damping:<\/p>
    addpath .changes\/round1<\/span>\r\n<\/pre>
    \r\nfunction<\/span> design = springMassDamperDesign(mass)\r\n\r\nif<\/span> nargin\r\n  m = mass;\r\nelse<\/span>\r\n  m = 1500; % Need to know the mass to determine critical damping<\/span>\r\nend<\/span>\r\n\r\ndesign.k = 5e6; % Spring Constant<\/span>\r\ndesign.c = 1e5; % Damping coefficient<\/span>\r\n\r\n\r\n<\/pre>
    [t,y] = simulateSystem(springMassDamperDesign);\r\nplot(y,t)\r\n<\/pre>\"\" 
    ...and submit. This is when I get a dose of humility and experience a world of pain. The toolbox maintainer declines my submission because this design fails a test already put in place intended to limit the overshoot of the response. See?<\/p>
    runtests(\"tests\/designTest.m\"<\/span>)\r\n<\/pre>
    Running designTest\r\n.\r\n================================================================================\r\nVerification failed in designTest\/testOvershoot.\r\n    ----------------\r\n    Test Diagnostic:\r\n    ----------------\r\n    Overshoot violation! Maximum overshoot is 0.01\r\n    ---------------------\r\n    Framework Diagnostic:\r\n    ---------------------\r\n    verifyLessThan failed.\r\n    --> The value must be less than the maximum value.\r\n    \r\n    Actual Value:\r\n       0.010846982843858\r\n    Maximum Value (Exclusive):\r\n       0.010000000000000\r\n    ------------------\r\n    Stack Information:\r\n    ------------------\r\n    In \/Users\/acampbel\/Library\/CloudStorage\/OneDrive-MathWorks\/repos\/msd_blog1\/tests\/designTest.m (testOvershoot) at 23\r\n================================================================================\r\n..\r\nDone designTest\r\n__________\r\n\r\nFailure Summary:\r\n\r\n     Name                      Failed  Incomplete  Reason(s)\r\n    =======================================================================\r\n     designTest\/testOvershoot    X                 Failed by verification.\r\n\r\nans = \r\n\r\n  1×3 TestResult array with properties:\r\n\r\n    Name\r\n    Passed\r\n    Failed\r\n    Incomplete\r\n    Duration\r\n    Details\r\n\r\nTotals:\r\n   2 Passed, 1 Failed, 0 Incomplete.\r\n   0.052733 seconds testing time.\r\n\r\n<\/pre>
    In retrospect this is easy to predict, there were tests after all. I should have run them before submitting. But there was nothing pointing me in their direction and I just missed it. For a simple example repo that might seem obvious, but for a \"real\" toolbox this can be hard to see.<\/p>
    Alright clearly there is more work to do after my contribution was declined tersely by an overworked toolbox author. But I am still up to the task. After learning that there is an overshoot requirement I can tweak my design to fit within these constraints:<\/p>
    addpath .changes\/round2<\/span>\r\n<\/pre>
    \r\nfunction<\/span> design = springMassDamperDesign(mass)\r\n\r\nif<\/span> nargin\r\n  m = mass;\r\nelse<\/span>\r\n  m = 1500; % Need to know the mass to determine critical damping<\/span>\r\nend<\/span>\r\n\r\ndesign.k = 5e6; % Spring Constant<\/span>\r\ndesign.c = 1.1e5; % Damping coefficient<\/span>\r\n\r\n\r\n<\/pre>
    [t,y] = simulateSystem(springMassDamperDesign);\r\nplot(y,t)\r\n<\/pre>\"\" 
    Looks good, does it pass the test?<\/p>
    runtests(\"tests\/designTest.m\"<\/span>)\r\n<\/pre>
    Running designTest\r\n...\r\nDone designTest\r\n__________\r\n\r\n\r\nans = \r\n\r\n  1×3 TestResult array with properties:\r\n\r\n    Name\r\n    Passed\r\n    Failed\r\n    Incomplete\r\n    Duration\r\n    Details\r\n\r\nTotals:\r\n   3 Passed, 0 Failed, 0 Incomplete.\r\n   0.011899 seconds testing time.\r\n\r\n<\/pre>
    Yes! Finally I must be done. However, when I submit this code I get another rejection because there is still a test failing for the mex file utility that I didn't even know about:<\/p>
    runtests(\"tests\"<\/span>)\r\n<\/pre>
    Running convecTest\r\n\r\n================================================================================\r\nError occurred in convecTest\/MatchesConvBaseline and it did not run to completion.\r\n    ---------\r\n    Error ID:\r\n    ---------\r\n    'MATLAB:UndefinedFunction'\r\n    --------------\r\n    Error Details:\r\n    --------------\r\n    Undefined function 'convec' for input arguments of type 'double'.\r\n    \r\n    Error in convecTest (line 6)\r\n    assert(isequal(convec(x,y), conv(x,y)), ...\r\n================================================================================\r\n.\r\nDone convecTest\r\n__________\r\n\r\nRunning designTest\r\n...\r\nDone designTest\r\n__________\r\n\r\nFailure Summary:\r\n\r\n     Name                            Failed  Incomplete  Reason(s)\r\n    ===============================================================\r\n     convecTest\/MatchesConvBaseline    X         X       Errored.\r\n\r\nans = \r\n\r\n  1×4 TestResult array with properties:\r\n\r\n    Name\r\n    Passed\r\n    Failed\r\n    Incomplete\r\n    Duration\r\n    Details\r\n\r\nTotals:\r\n   3 Passed, 1 Failed, 1 Incomplete.\r\n   0.036491 seconds testing time.\r\n\r\n<\/pre>
    Alright, at this point I see that there is some utility that I wasn't changing, using, or even familiar with and it's test is failing. Furthermore, I realize that it is failing because it isn't compiled. I have no idea how to compile this mex file, and at this point I give up because I hadn't planned to invest this much time into this contribution. I don't have time to learn all the details of this repo (I just wanted to tweak the damping coefficient!). After giving up I leave with a bad taste in my mouth. I am probably done trying to contribute to this code base, and actually may even think twice before trying to contribute to some other code base. Not good. No buena. Nicht gut.<\/p>
    Enter buildtool<\/b><\/p>
    All of this pain can be addressed through using this new build tool. As a new contributor, all I need to know is that I need to invoke the build tool to go through the author's intended development workflow. I need to learn this the first time, but once I am familiar with this standard framework I can interact with any other project<\/b> that is also using the build tool. Once I see that the root of the project has a file called buildfile.m<\/tt><\/b> I know I am in business and I can do anything the author intended, including things like running tests and compiling mex files, by simply invoking the tool. Let's try it:<\/p>
    buildtool\r\n<\/pre>
    ** Starting mex\r\nBuilding with 'Xcode with Clang'.\r\nMEX completed successfully.\r\n** Finished mex\r\n\r\n** Starting setup\r\n** Finished setup\r\n\r\n** Starting test\r\nRunning convecTest\r\n.\r\nDone convecTest\r\n__________\r\n\r\nRunning designTest\r\n...\r\nDone designTest\r\n__________\r\n\r\n  1×4 TestResult array with properties:\r\n\r\n    Name\r\n    Passed\r\n    Failed\r\n    Incomplete\r\n    Duration\r\n    Details\r\n\r\nTotals:\r\n   4 Passed, 0 Failed, 0 Incomplete.\r\n   0.16678 seconds testing time.\r\n\r\n** Finished test\r\n\r\n<\/pre>
    Isn't that beautiful? I didn't have to know anything about how the project is built and I could get rolling quickly. I can make my small change, everything that needs to happen (e.g. building a mex file) happens and then we can confirm it doesn't fail the tests. It makes baking in high quality easy(er).<\/b><\/p>
    How's it done?<\/b><\/p>
    I have been focusing on the perspective of the unfamiliar contributor. How can the author\/owner use this to set up for success? Well this is super simple and leverages an easy to work with scriptable MATLAB interface as the fundamental framework. You start by creating your buildfile.m<\/tt><\/b>, which is a function that creates your build plan.<\/p>
    \r\nfunction<\/span> plan = buildfile\r\n\r\nplan = buildplan(localfunctions);\r\n\r\nend<\/span>\r\n\r\n<\/pre>
    Passing all of the local functions when you create your build plan makes it easy to define simple tasks. This enables you to create tasks from any function that ends in the word Task<\/tt><\/b> (or task<\/tt><\/b> or _task<\/tt><\/b> or tAsK<\/tt><\/b>, etc). The first comment in the function (the H1 line) gives a task description. For this case we have 3 tasks we'd like to add.<\/p>
    A setup task<\/b><\/p>
    \r\nfunction<\/span> setupTask(context)\r\n% Setup path for the build<\/span>\r\naddpath(fullfile(context.Plan.RootFolder,\"toolbox\"<\/span>));\r\nend<\/span>\r\n\r\n<\/pre>
    This task ensures that the right paths are in place for the build. You might ask whether this should be done using a MATLAB Project, and the answer is yes absolutely! That is a better way. For now we are building this in but will projectify it in a later post.<\/p>
    A mex task<\/b><\/p>
    \r\nfunction<\/span> mexTask(~)\r\n% Compile mex files<\/span>\r\n\r\nmex mex\/convec.c<\/span> -outdir<\/span> toolbox\/<\/span>;\r\nend<\/span>\r\n\r\n<\/pre>
    This is a pretty simple compile in this example, but for many projects this step can be more involved. Simple or complex, here is where you can make it trivial for the newcomer.<\/p>
    A test task<\/b><\/p>
    \r\nfunction<\/span> testTask(~)\r\n% Run the unit tests<\/span>\r\n\r\nresults = runtests(\"tests\"<\/span>);\r\ndisp(results);\r\nassertSuccess(results);\r\nend<\/span>\r\n\r\n<\/pre>
    Straightforward. Now that those tasks are defined and automatically included in your build file anyone can see what tasks can be run:<\/p>
    buildtool -tasks<\/span>\r\n<\/pre>
    mex   - Compile mex files\r\nsetup - Setup path for the build\r\ntest  - Run the unit tests\r\n\r\n<\/pre>
    Great, we can see our 3 tasks, but as you might predict that these tasks can't be run in just any order. The tests won't pass unless the proper code is on the path and the mex file is built. These task dependency relationships can be defined in the main function as you setup your plan. We need to add these dependencies, and while we are at it, let's setup a default task so that buildtool<\/tt><\/b> will work without even passing any arguments.<\/p>
    \r\nfunction<\/span> plan = buildfile\r\n\r\nplan = buildplan(localfunctions);\r\n\r\nplan(\"test\"<\/span>).Dependencies = [\"mex\"<\/span>, \"setup\"<\/span>];\r\n\r\nplan.DefaultTasks = \"test\"<\/span>;\r\nend<\/span>\r\n\r\n<\/pre>
    Now we can invoke it by default by just calling buildtool<\/tt><\/b> (as we did above) or we can invoke a specific task we'd like to run such as mex and it will just run what is required for that task:<\/p>
    buildtool mex<\/span>\r\n<\/pre>
    ** Starting mex\r\nBuilding with 'Xcode with Clang'.\r\nMEX completed successfully.\r\n** Finished mex\r\n\r\n<\/pre>
    Here is the full buildfile for your reference:<\/p>
    \r\nfunction<\/span> plan = buildfile\r\n\r\nplan = buildplan(localfunctions);\r\n\r\nplan(\"test\"<\/span>).Dependencies = [\"mex\"<\/span>, \"setup\"<\/span>];\r\n\r\nplan.DefaultTasks = \"test\"<\/span>;\r\nend<\/span>\r\n\r\nfunction<\/span> setupTask(context)\r\n% Setup path for the build<\/span>\r\naddpath(fullfile(context.Plan.RootFolder,\"toolbox\"<\/span>));\r\nend<\/span>\r\n\r\nfunction<\/span> mexTask(~)\r\n% Compile mex files<\/span>\r\n\r\nmex mex\/convec.c<\/span> -outdir<\/span> toolbox\/<\/span>;\r\nend<\/span>\r\n\r\nfunction<\/span> testTask(~)\r\n% Run the unit tests<\/span>\r\n\r\nresults = runtests(\"tests\"<\/span>);\r\ndisp(results);\r\nassertSuccess(results);\r\nend<\/span>\r\n\r\n\r\n<\/pre>
    Alright with that I am going or send you off to begin your MATLAB project development adventures with the new build tool. We'd love to hear your feedback. Let's make this a series! I am going to blog a few more times on this so you can see this project grow in capabilities and really start to leverage this build framework. Also, we are working like crazy on future capabilities for this tool. So on multiple fronts this is just the beginning of much more to come.<\/p>