Having to modify generated files...

[farble1670]

Hello, we are finding it necessary to modify generated files. We have a few different cases, but just taking the first example, we had to change generated/OSWrappers.cpp as the variant of FreeRTOS we're using has slightly different function names.

Is there a system for dealing with situations like this?

Thanks.

[Pavel A.]

The system exist and it is called "version control". Check in the current state so you can return to it if something goes wrong. Make the changes. Build, test. When satisfied, check in the changes. Repeat.

 

[farble1670]

Thanks @Pavel A. for the snarky answer. I wasn't aware of version control. 

A system that modifies files under source control when it BUILDS is fundamentally broken. 

[codebuk]

Hi,

I use goto:-) 

For example I used this to instrument some code and check the return values from FreeRTOS startup code in main.c  I guess you could check for changes in the generated code in a post build script.

 

	printf("Transferring control to FreeRTOS\n");
	goto check_fr; //replace generated code so we can check return values.
 /* USER CODE END 2 */

 /* Init scheduler */
 osKernelInitialize();

 /* Call init function for freertos objects (in cmsis_os2.c) */
 MX_FREERTOS_Init();

 /* Start scheduler */
 osKernelStart();

 /* We should never get here as control is now taken by the scheduler */

 /* Infinite loop */
 /* USER CODE BEGIN WHILE */

	osStatus ret;

check_fr:

	printf("osKernelInitialize\n");
	ret = osKernelInitialize();
	if (ret != osOK) {
		printf("FreeRTOS osKernelInitialize failed\n");
	}
	/* Call init function for freertos objects (in freertos.c) */
	printf("MX_FREERTOS_Init\n");
	MX_FREERTOS_Init();
	/* Start scheduler */
	printf("osKernelStart\n");
	ret = osKernelStart();
	if (ret != osOK) {
		printf("FreeRTOS osKernelStart failed\n");
	}

	/* We should never get here as control is now taken by the scheduler */
	/* Infinite loop */

	while (1) {

	}
 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */

 /* USER CODE END 3 */
}

 

 

[BarryWhit]

I've not done this and haven't seen any threads by anyone who has, but in principle you could modify the templates used for code generation, or use custom templates. See my comment here which shares the few details I do know.

 

Other comments in the thread may be relevant to your concerns (at least in how others deal or dislike dealing with such issues).

 

Update: 

Well, whaddayaknow. There is some documentation on doing this, if only I'd look for it.

UM1718: Section "Custom code generation"

[Pavel A.]

My answer was not snarky. As @BarryWhit found recently, CubeMX has a well known template tool under the cover, and the templates can be tweaked. But this way is cumbersome and IMHO only these who professionally make Cube extensions and feature packs will use it. Users that just need to do a few fixes in a few projects have simpler, more straightforward ways, such as pre and post generation scripts. Project manager->Code generation -> User actions.

/* For me the main reason to not use custom templates is lack of information on the object model of the Cube project. UM1718,  pg. 285 gives example of accessing the model: ${peripheralParams.get("RCC").get("LSI_VALUE")}. I'd like not only get the properties but change and add. For example this would let me to add a serial-based network interface and convince Cube to generate LwIP code around it.  Anyway these template things are 20 th century. We should be looking towards AI based tools these days. */

Version control is very powerful and absolutely must be used with generation tools, to detect unwanted changes (bugs) and make deliberate changes in a sane and manageable way.

[BarryWhit]

Pavel Makes some good points. Though I don't agree with all of them.

 

As for AI, that'll come eventually, but it's certainly not a solution for OP right now, nor for several more years. So there's no point bringing that up.

 

I agree that customizing templates is a challenge (you may end up doing a lot of extra work not strictly related to your project). But I also think part of the problem is that no one seems to have "scaled that wall". i.e. there's not a lot of information, or reports from those who have done it. If anyone pushes through the difficulty of being first, and creates a few well-written posts or blog posts describing the process, I think the barrier to entry will be substantially lowered, and doing this could become far less "niche" than it is currently. On the internet, once someone describes their successes,  usually many are happy to follow.

 

As for version control - you could indeed a long way with patches (which depending on your mods might apply cleanly almost always) and git hook scripts. I think in itself version control is not itself a solution though. If you have to regenerate, you also have to make the modifications each time. And that requires a mechanism that minimizes your pain. Manually Rebasing/Merging/Cherry-picking against a commited versions might work, but it's certainly not  friction-free. Of course everyone should be using version control these days, but I don't think that in itself solves OP's problem.

 

Importantly, I think Pavel's mention of post-generation scripts (for applying a patch set) is I think a very practical and relatively painless solution for OP to achieve their goals, and I think it's worth seriously considering.

 

[MM..1]

TouchGFX have many versions and is hard to handle your idea here. More better is simply exclude generate dfiles from build and create your own...

[farble1670]

---

@MM..1 wrote:

TouchGFX have many versions and is hard to handle your idea here. More better is simply exclude generate dfiles from build and create your own...

---

Is there a well-defined way to accomplish that?

[Pavel A.]

> . I think in itself version control is not itself a solution though.

Of course version control is not a solution itself but it gives confidence and power to change the generated stuff and stay in control. Good version control comes with convenient diffing and merge tools. CubeIDE inherited some of that from the upstream Eclipse.

AI also will come much earlier than you think. My employer does not subscribe to the Github Copilot yet, but even now I guess it is possible to feed a simple C/C++ project to the AI and ask it to refactor (rename functions, files etc). Or to write a script to do this.

[BarryWhit]

> Good version control comes with convenient diffing and merge tools.

I think OP wanted to *generate* the right code to begin with, instead of finding better ways to maintain and apply a  patchset.

 

> AI also will come much earlier than you think. 

I, for one, welcome our new dystopian overlords. Though, we should have voted for Kang (very obscure reference, don't feel bad).

[Pavel A.]

So what means "well defined"? Something automatic? Point and click?

[farble1670]

---

@Pavel A. wrote:

So what means "well defined"? Something automatic? Point and click?

---

Something other than having to go in after generation and reconcile the tool-edited version of generated file.

I was mainly wondering if there's some configuration somewhere like "don't generate this file", or a way to move the problem generated code into non-generated code. I'm hearing there is not.

Thanks everyone for the feedback.

[ferro]

Hi @farble1670 

Is python script not an option ? Or even a Windows batch file could do that I recon - string find&replace. I got something similar running pretty qiuckly (mostly programmed by GPT).

[BarryWhit]

> I was mainly wondering if there's some configuration somewhere like "don't generate this file", 

really? because you never asked that question. There are some knobs for controlling some of that, for peripherals.

Also "don't generate" is quite easy to do by just deleting with a post-generation script. if that's what you mean.