Add persistent sections to the generated files

[martonmiklos]

Inspired from the ST CubeMX tool it would be useful to have code sections in the generated codes which would persist between code generations.

Basically the output files needs to be read and parsed before the code generation and a lookup should be created from the contents between the following style comment pairs:

/* USER CODE BEGIN <classname> public declaration */
/* USER END BEGIN <classname> public declaration */

And when generating the code this lookup has to be checked for the currently generated class and the specific saved section needs to be generated.

At the moment I am thinking about the following sections to be supported:
public|protected|private declaration
implementation

But this list could be extended with pre/post sections of the class fields.

Using this feature it would be easy to add custom formatter methods to the generated codes for e.g.

Any comment on this topic is welcome!

[cornelius]

I see that this could be a useful feature. I have some doubts about maintaining these user generated sections in the files which are automatically generated, though.

There are some cases where it's advantageous to have a clear separation between generated files and user-edited files. This makes it easier for build systems to determine which files have been modified or which files need regeneration. It also makes it easier to keep a clean history in version control, because autogenerated files don't need to be under version control at all and the build system can take care of them. That's more difficult when there is also manually edited code in there, then you need to check them in and need to somehow deal with who commits the autogenerated code.

Not requiring special comments in the code which have semantics beyond what the C++ compiler knows about also would be preferable.

I see two options to separate autogenerated files and user-maintained files while still enabling the feature to have more control about the autogeneration and inject user-defined parts there:

1. Use the native C++ language mechanisms to keep separate files. That could be things like generating a base class and creating a subclass to add user-maintained code.

2. Keep the user-maintained sections in a separate file which acts as a hint for the code generation. It would be read by kxml_compiler and processed during code generation to insert the code snippets. The format of these code generation hint files would be up for discussion but could be freely chosen as only kxml_compiler would need to understand it. The concept is a bit similar to how the ugh (UI generation hints) file (see e.g. this example) work in kxforms.

[martonmiklos]

Many thanks for your feedback!

The problem with the 1. approach that it could work for when generating XML with the autogenerated code, but the autogenerated parsers would still offer the base classes.

But as you mentioned the second option a combined approach came into my mind: what if we create a lookup file which could tell the kxml_compiler to simply replace a given class with an user written class from a separate file. I thinkking about not including code snippets, but directly including user headers and create the user classes in the parse and writer methods where there is a matching lookup .

I think we should include the following info in the lookup file:

• Target XML field
• Include file path (relative/global)
• Custom class name