• State Verified Answer
  • Replies 5 replies
  • Subscribers 64 subscribers
  • Views 237 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 324479
Options

Generation of .matter files from .zap files

mlampacher

Hi,

I am currently looking into setting up a Matter project (based on the template) and reached ZAP and the required files. As far as I understood, the ".zap" file is the only file that is actually needed, the corresponding ".matter" file is generated from the ".zap" file (as documented here: https://project-chip.github.io/connectedhomeip-doc/code_generation.html#ensure-you-have-a-matter-file).

My idea is to not even keep the generated files (e.g., not place them under version control) and instead generate all files from the ".zap" file. In the template, however, you're using "BYPASS_IDL" and as described in the example for adding a new cluster (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.0/nrf/protocols/matter/getting_started/adding_clusters.html) you're relying on pre-generated files.

My real question: Is it somehow possible to really generate all files during the build, or what is the reason why the samples use "BYPASS_IDL"?

I'm a bit dumbstruck by the Matter CMake integration, which actually uses the "generate.py" generator, but instead of first passing the ".zap" file, the function `chip_codegen` assumes that the ".matter" file already exists ... This integration could generate the ".matter" file during the build step but simply doesn't.

Parents
  • 0

    Hi,

    Due to the Easter holidays in Norway, we are less staffed than usual. You can expect an answer sometime next week,

    Sorry for the inconvenience and thanks for your patience. 

    Regards, 
    Amanda

  • 0 in reply to Amanda Hsieh

    I had a deeper look into ZAP and the generator scripts and I guess I came to the same conclusion as you did:

    • The CMake integration of the Matter project does not have any targets to generate the .matter file from the .zap file (yet).

    • The chip_codegen.cmake, however, assumes that a .matter file is used (with the same name as the .zap input file, except for the file type) as input for the generate.py script.

    • Therefore, it is anyhow always necessary to trigger the code generation either via ZAP's GUI or call generate.py elsewhere.

    • Thus the code generation provided by the CMake integration may as well be skipped altogether (it is also very rare to update the .zap file and virtually impossible to forget generating the files since otherwise nothing will work anyhow), also saving some compile/configuration time.

    I'm still a bit unsure why the Matter project uses a .matter file even though the same information is present in the .zap file, which for now is always present (and can be used with generate.py to generate the correct set of files, also shown in your documentation for adding a cluster to the example application).

    They mention in their codegen documentation that they "strive to make them contain only Matter-specific data" and that the "codegen.py" has less dependencies (but currently also doesn't generate the full set of required files (?)) and that linting of .matter files is possible.

    I guess it's still a lot of "work in progress". Due to the large amount of scripts and their awkward path handling (e.g., assuming either absolute paths or paths relative to the Matter root directory as parameters) this is currently still very confusing.

    They also mention that "Currently .matter files are generated from .zap files during the application specific codegen." but that is not true for the CMake integration - or at least I couldn't find a single step where the .matter file would be generated.

Reply
  • 0 in reply to Amanda Hsieh

    I had a deeper look into ZAP and the generator scripts and I guess I came to the same conclusion as you did:

    • The CMake integration of the Matter project does not have any targets to generate the .matter file from the .zap file (yet).

    • The chip_codegen.cmake, however, assumes that a .matter file is used (with the same name as the .zap input file, except for the file type) as input for the generate.py script.

    • Therefore, it is anyhow always necessary to trigger the code generation either via ZAP's GUI or call generate.py elsewhere.

    • Thus the code generation provided by the CMake integration may as well be skipped altogether (it is also very rare to update the .zap file and virtually impossible to forget generating the files since otherwise nothing will work anyhow), also saving some compile/configuration time.

    I'm still a bit unsure why the Matter project uses a .matter file even though the same information is present in the .zap file, which for now is always present (and can be used with generate.py to generate the correct set of files, also shown in your documentation for adding a cluster to the example application).

    They mention in their codegen documentation that they "strive to make them contain only Matter-specific data" and that the "codegen.py" has less dependencies (but currently also doesn't generate the full set of required files (?)) and that linting of .matter files is possible.

    I guess it's still a lot of "work in progress". Due to the large amount of scripts and their awkward path handling (e.g., assuming either absolute paths or paths relative to the Matter root directory as parameters) this is currently still very confusing.

    They also mention that "Currently .matter files are generated from .zap files during the application specific codegen." but that is not true for the CMake integration - or at least I couldn't find a single step where the .matter file would be generated.

Children
Related

core_v2_widget.Hide()