Closed philiprodrigues closed 3 years ago
I edited buildsys.org
but I don't have org-mode set up properly to recreate the "results" sections of the examples, so those need to be re-run.
Thanks!
Out of curiosity, how does the render-deps
command differ from imports
?
The .d
files that render-deps
generates consist of Makefile-style dependency lines like:
myfile.hpp : myfile.jsonnet sometemplate.hpp.j2 someotherimport.jsonnet
so render-deps
needs to know ~everything that render
knows (the target name, the jsonnet input and the template name). imports
only takes one input (model or template), and it doesn't know the target name (myfile.hpp
in this example). The .d
file format is pretty simple, and one could alternatively try to stitch it together from moo import
outputs in shell script/CMake, but after some discussion, Brett and I concluded that render-deps
was the least bad option.
Understood. daq-cmake
uses moo imports
but it has to be called several times to cover model, schema and templates. Looks like render-deps
is going to simplify things quite a bit.
Thanks!
That was very much my motivation! I have some modifications to the daq-cmake
code that use an earlier iteration of this functionality. Once i tidy it up, I'll make a daq-cmake
PR for comments
As usual, issues rather than PR are highly appreciated
This PR adds a
moo render-deps
command that creates a.d
file containing Makefile-style dependencies. The typical use is to usemoo render-deps
in conjunction with amoo render
command: the render command creates an output file, while the render-deps command creates the.d
file that describes the dependencies of that output file.Also included are examples of how to use the generated
.d
file with a Makefile-based build and a CMake build. The CMake build requires the ninja backed generator. It looks like CMake 3.20 will be out soon, with support for using the.d
files with the Makefile backend.