This improvement requires you to be able to access the dzn
client from your command line. To learn how to do this, refer to
or follow the instructions on how to set your
PATH variable after
installation of Dezyne through the Dezyne-IDE.
In a way, generated code from Dezyne models can also be seen as temporary files, just like the *.o files from the previous paragraph. The source files for the generated code are your *.dzn files, and by including the generation of code in a makefile recipe it becomes easy to compile the application with only the makefile and source code in your VCS.
The generation of code from Dezyne models and its removal before committing can both be automated in the makefile. The generated code shares a version dependency with the runtime files, so to avoid any clashes on that aspect the example makefile also has a recipe to download the runtime.
For the generation of C++ code and the downloading of the Dezyne runtime, the following recipes were added:
VERSION = 2.3.3 CURRENT := $(shell dzn query | grep '*' | sed 's,\* ,,') ifneq ($(VERSION),$(CURRENT)) $(info current version: $(CURRENT) is not equal to selected version: $(VERSION)) endif runtime: | $(RUNTIME)/dzn for f in $(shell dzn ls -R /share/runtime/c++ | sed 's,/c++/,,' | tail -n +3); do \ dzn cat --version=$(VERSION) /share/runtime/c++/$$f > $(RUNTIME)/$$f; \ done touch $ $(RUNTIME)/dzn: mkdir -p $ generate: $(wildcard *.dzn) for f in $^; do dzn -v code --version=$(VERSION) -l c++ -o $(SRC) --depends=.d $$f; done touch $
These additions check the version you’re using against the newest possible version of Dezyne so you are notified if there is a new Dezyne available. The runtime recipe checks if the required folder structure is already present; if it is not, it will be created. Then, it checks Verum’s runtime repository and downloads the respective files for the C++ runtime.
The generate recipe checks for all *.dzn files in the root
directory of your project where your makefile is located and generates
C++ code for all of the interfaces and components in the files. The
generated code is stored in the folder specified by the
variable that was declared earlier in the makefile; this ensures that
foreign and generated code exist in the same directory. Lastly, the
--depends option ensures that extra *.dzn.d files are
generated that provide information about what *.cc and
*.hh files are generated from their respective *.dzn files
and their dependencies. The information in these files can be used for a
final step in the VCS improvements: cleaning up generated code.
clean_generated: $(RM) `grep -h dzn $(SRC)/*.dzn.d | sed -e 's,:.*,,' -e 's,%,.,g'` $(RM) $(RUNTIME) $(RM) runtime generate
The recipe for cleaning up generated code is a bit harder to read, but in essence what it does is it reads the contents of the *.dzn.d files (that were generated with the --depends option of dzn code generation). In these *.dzn.d files, the names of generated files can be found; the make recipe clean_generated then removes all of the files it has found from the contents of the *.dzn.d files. The recipe also removes the runtime that was downloaded.
This should cover everything that is included in the example makefile. Depending on your preferences, you can choose to include or leave out some of its features; maybe you don’t care about having generated files in your VCS for example. As long as you include the core features discussed in Breakdown of example makefile the core, you will be able to compile your application consisting of generated and foreign code.