xod
xod copied to clipboard
Add `--split` argument for `xodc transpile`
Rationale
Currently, the generated code is output as a single chunk. In some advanced usage scenarios when a custom build system is involved that is undesirable. Particularly, in the case of the FreeRTOS-oriented project where multiple XOD programs run side by side, the code generated by each program should be split, so that the common parts could be re-used. This guarantees code deduplication at the binary level.
User story
Consider a project my-proj-qux with patches main and foo. Let’s assume it also uses some nodes from xod/core and community/customlib. Then, I can run the following:
xodc transpile my-proj-qux.xodball main --split --output ./build/
This will transpile the project and put generated code split by files to the build subdir:
build/
runtime/
formatNumber.h
formatNumber.cpp
listFuncs.h
listViews.h
memory.h
memory.cpp
preamble.h
runtime.cpp
# and other program-independent source files
XOD.h
nodes/
my_proj_qux__foo.h
xod__core__add.h
xod__core__flip_flop.h
community__customlib__superpatch.h
# and all other C++ node implemetations referred
main/
my_proj_qux__main.cpp
I can transpile another project using the same subdir and its sources will deeply override the existing files and dirs, leaving other existing files as-is. Effectively it will create a minimal project to run multiple programs simultaneously.
All the source files include correct #include directives and header guards, so that I can successfully compile and link together all *.cpp as usual (e.g. with make and avr-gcc).
Acceptance criteria
- [ ] I can
xodc transpile --splitas described above and have all the source files layed out - [ ] If
--splitwith--outputunspecified, show an error and exit - [ ] If
--splitwith--outputpointing to a file, show an error and exit - [ ] If
--splitwith--output=foo/barandbardoes not exist, create it - [ ] If
--splitwith--output=foo/barandfoodoes not exist, show an error and exit - [ ]
runtime/XOD.hsums up all the public XOD API in a single file and get’s#include’d innodes/*.handmain/*.cpp
How to test
- Have a shell script to
xodc transpile --splita sample project - Have a
Makefilewhich shows how to successfully build that project for AVR target
main.cpp— an entry point that ties everything together
Shouldn't the file have a unique name? In the case when several projects are transpiled into one directory with overwriting?
Good starting point but many details are missing or overlooked:
(1)
implementations of used patches, each one in a separate file named like
user__libname__patchname.cpp
The implementations are potentially C++ template-based, so they can’t be .cpp. They have to be .h. Anyway, you will refer nodes’ evaluate in transactions, so it can’t be just hidden in .cpp.
(2)
The acceptance criteria are missing. How can we judge the feature is implemented or not? The criteria should include a description of specific steps to successfully consume the artifact.
(3)
xodс produces a static runtime.cpp file
No-no. First, you can’t refer anything hidden in .cpp. Second, there are templates that can’t be put in .cpp. Third, and most importantly, the current monolith gluing is done because of that single-file requirement; no reason to union the carefully split source files in this mode.
(4)
Edge cases not described:
- What if
./foo/bardoes not exist? - What if
./foo/barexists but not empty or not a directory at all?
(5)
As @knopki mentioned, how a user should set the main file name?