Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use common filters in custom templates #310

Closed
willeccles opened this issue Jun 13, 2023 · 6 comments
Closed

Unable to use common filters in custom templates #310

willeccles opened this issue Jun 13, 2023 · 6 comments
Assignees
Labels
bug Something isn't working

Comments

@willeccles
Copy link

(Copied from original forum post here.)

I intended to write my own templates for C generation, so I went ahead and copied the contents of lang/c/templates to a new directory. Before attempting to modify them, I tried to generate C headers with these new templates. The command I am running is as follows (I am testing with the public_regulated_data_types):

nnvg --target-language c --target-endianness=little --enable-serialization-asserts --templates templates public_regulated_data_types/reg --lookup-dir public_regulated_data_types/uavcan

If I simply remove --templates, all is well and it generates normally. However, after adding the template directory, I get the following:

nunavut.jinja.jinja2.exceptions.TemplateAssertionError: no filter named 'remove_blank_lines'

What am I missing? I can't seem to make this work at all. The documentation suggests that I should be able to use these just fine.

@thirtytwobits
Copy link
Member

Huh. I have this use case covered in the test suites. Let me take peek...

@thirtytwobits thirtytwobits added the bug Something isn't working label Jun 14, 2023
@thirtytwobits thirtytwobits self-assigned this Jun 14, 2023
@thirtytwobits
Copy link
Member

Confirmed. Looking into the issue now...

@thirtytwobits
Copy link
Member

fyi, the bug is in the serialization code generator. If you use --omit-serialization-support it does work.

@thirtytwobits
Copy link
Member

thirtytwobits commented Jun 14, 2023

Found one bug related: support loaders shouldn't use the external template path as "support" == "internal" in Nunavut. Because of this the loaders are getting confused about duplicate serialization.j2 templates.

A plausible albeit ugly patch to fix that bug:

diff --git forkSrcPrefix/src/nunavut/jinja/__init__.py forkDstPrefix/src/nunavut/jinja/__init__.py
index c60d67bafcb909e7631db94d6d8c04e1d77fd20b..9897e52ad59086774b8bbb84655d91f3d23445fb 100644
--- forkSrcPrefix/src/nunavut/jinja/__init__.py
+++ forkDstPrefix/src/nunavut/jinja/__init__.py
@@ -783,6 +783,7 @@ class SupportGenerator(CodeGenerator):
     """
 
     def __init__(self, namespace: nunavut.Namespace, **kwargs: typing.Any):
+        kwargs.update(templates_dir=None)
         super().__init__(namespace, builtin_template_path="support", **kwargs)
 
         target_language = self.language_context.get_target_language()

thirtytwobits added a commit that referenced this issue Jun 14, 2023
@willeccles
Copy link
Author

fyi, the bug is in the serialization code generator. If you use --omit-serialization-support it does work.

Confirmed, this fixes it. This is actually excellent news for my use case. I need to use the default templates once, then use my templates for some auxiliary things (which do not include serialization). Thanks for looking into this!

thirtytwobits added a commit that referenced this issue Jun 14, 2023
`--template` argument should not apply to support files.
@willeccles
Copy link
Author

Closing as this is fixed by #311 (2.1.1).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants