Code Generation Modifiable?

[JAlbr.1]

Good Day,

The project I'm working on has some guidelines that I'd prefer to follow if possible. One such standard involves moving code critical to the TouchGFX around, subsequently breaking the build. Two things that I'd really like to do are: 1. Move the .ioc folder out of the root to a different subdirectory and 2. Not have the Middlewares folde regenerate every time I build using the designer, as I've moved that as well. 

If it's not possible I will just have to move the .ioc file back and write a script that deletes the middleware folder after each build.

Thanks,

Jack

[JAlbr.1]

Looks like I also have problems with deleting .cproject. For background I am generating my .elf file via CMake, and do not need any of those project files.

[Tesla DeLorean]

Don't use Code Generation?

Or just do it sparingly into a sandbox and then merge what you need into your mainline code / project maintaining your own standards and expectations. 

[JAlbr.1]

I mean, that's certainly a solution, but with multiple people on the project, and looking long-term down the road at code maintenance, it'd be nice to not have to communicate that generating new touchgfx code will generate a bunch of unnecessary stuff that they should delete. All I want is to be able to move the output of the Middlewares folder, I don't see a good reason why I should be prohibited from doing that. Sure it might break the "Run Simulator" command in the tool, but I'm using CMake to run and debug the simulator on my own, so I can change include paths there. It's much more useful that way anyway.

[JAlbr.1]

Was able to fix the .ioc problem by correcting the path in the .touchgfx.part file. Now trying to fix the other issues.

[Pavel A.]

With multiple people on the project, somebody one should be assigned to make changes in the .ioc. Then as @tesla advised, generate code in a sandbox and merge into the project (or let other people merge the changes). Use a source control to handle several branches as needed, and track changes.  If the "middleware" components change, keep them in the source control too.

[JAlbr.1]

We're ditching the mx cube altogether (generated code does not follow our code standards), so no changes should ever be made to the .ioc. We have our code base already set up on Azure Dev Ops, complete with unit tests, continuous integration and a strict pull request process.

In our code base we try to keep all external libraries and code (HALs, ETL, USB, etc.) in an "External" directory that is common among all projects. That's where I'd like to put the Middlewares folder generated by the TouchGFX Designer.

I'm not asking for process strategies for a singular TouchGFX project. I'm asking if there's a way to customize the build output to fit our process. If not that's fine, we'll find a way around it, but I feel that my question is being misrepresented, here.