search

brettviren / moo

ruminants on module oriented programming
GNU General Public License v3.0
4 stars 4 forks source link

Issue getting import info on model file #5

Closed jcfreeman2 closed 3 years ago

jcfreeman2 commented 3 years ago

As part of looking into building support for code generation into daq_add_plugin by using the moo.cmake's moo_codegen function (https://github.com/DUNE-DAQ/daq-buildtools/issues/47) I've run into an issue in trying to reconstruct what's done in appfwk's generate.sh function. Ostensibly the issue is with the moo_deps_name function in moo.cmake, but I get the same problem when I run moo from the commandline with the same arguments as get used in moo_codegen's execute_process call. Working from the base of a development area, I can get import info from a template file without a problem. E.g.:

moo -T $PWD/sourcecode/appfwk/schema -M $PWD/sourcecode/appfwk/schema -g '/lang:ocpp.jsonnet' -A path="dunedaq.appfwk.fdp" -A ctxpath="dunedaq" -A os="appfwk-fdp-schema.jsonnet" imports appfwk-structs.hpp.j2

yields 

/home/jcfree/daqbuild_moo_issue/sourcecode/appfwk/schema/appfwk-cpp.hpp.j2

So far, so good. However, if I try getting import info from a model file, e.g.

moo -T $PWD/sourcecode/appfwk/schema -M $PWD/sourcecode/appfwk/schema -g '/lang:ocpp.jsonnet' -A path="dunedaq.appfwk.fdp" -A ctxpath="dunedaq" -A os="appfwk-fdp-schema.jsonnet" imports appfwk-model.jsonnet

I end up with

RuntimeError: RUNTIME ERROR: function parameter os not bound in call.
    Top-level function

i.e., somehow the TLAs aren't getting bound to the arguments of the function in appfwk-model.jsonnet. Is there an issue with the chant?

brettviren commented 3 years ago

Hi @jcfreeman2 sorry for the delay, I was off yesterday.

You are exactly correct. The imports function is broken in that it doesn't honor TLAs. I'll fix this!

One comment about TLAs which might make the daq_codegen layer simpler. The current examples in appfwk/schema/ etc use a single common "model" file. For this single model to wrok it must factor out any info specific to a schema to be provided as the various TLAs. We could instead provide a per-schema model file which "bakes in" these TLAs as local variables and then imports/calls the common model on them. The DAQ CMake layer could then get out of the business of managing these -A values. Let me know if that sounds like a useful change and I can help provide some new specific "model" files in appfwk/schema/ etc.

brettviren commented 3 years ago

TLAs should now be properly passed for moo imports. Some new test/examples are added to the docs and will run during document generation:

https://brettviren.github.io/moo/buildsys.html#imports

Thanks for finding this!

jcfreeman2 commented 3 years ago

No prob. Just tried checking the imports from the model file I described in my earlier comment and confirmed it's working.

jcfreeman2 commented 3 years ago

Also, I don't have a particularly strong opinion on this, but if it's not too much trouble I think it makes sense to move TLA responsibility out of the CMake layer and thus have the CMake layer focus file dependency issues rather than the actual code in the files.