Why does the library compiler app try to execute the code when I supply an example driver?

I am building a shared library using the Library Compiler App. I am using the mwArray API.

I am including in the .prj project file a sample driver in the "Samples" section of the Library Compiler GUI.

When I click "Package" to compile everything, it seems to spin forever. By accident, I discovered that if I had a breakpoint set in the code somewhere, it would stop at this breakpoint during packaging. Examination of variables indicates that the entrypoint is called with the values specified in the sample driver, but the sample driver itself does not appear in the stack trace. The functions appearing just below the entrypoint in the stack trace are built-in compiled p-file functions called 'ExampleParser.getVariables' and 'ExampleParser.getArgumentValidation'.

So the Library Compiler App has apparently parsed the sample driver, gathered the inputs contained therein, and invoked the entrypoint (which, with the inputs given, results in a long-running calculations!). Why on earth does it need to perform a complete execution of the code to take the matlab example source and turn it into a c++ example source? It just sits there spinning on "Packaging…"

What is Mathworks doing? To prevent this from happening I have to put guard-code in my entrypoint to see if 'ExampleParser.getVariables' is just below it in the stack trace in dbstack, and if so, return.