This post is about code generation in POK and how the libpart target can be included in the automatic generation process. First I will discuss where the configuration for the generation is done; Second I talk about the reasons, why I won’t intercept this process and which solution I settled with.
How Makefiles are generated
Like the name ‘generated-code’ would suggest, every file below this directory is generated by ocarina. But I wondered: Where are the specifications for this process? After a vain search through the POK sources I looked at the ocarina sources. Where else could the specs be? And here are a couple of files name ocarina-backends-pok_c-* . One of them is named ocarina-backends-pok_c-makefiles.adb and in the procedure Visit_Processor_Instance the main Makefile is written. Right below the kernel Makefile is created, too. Every line that shows up in the generated Makefiles is specified here and depending on your architecture and BSP it is written out. But where are the partition Makefiles created? In the procedure Visit_Process_Or_Device_Instance. And here we are the point where I want to include libpart as an Makefile to be included and as a target.
Get libpart into the generation
To get libpart into the Makefile generation I need to change ocarina source code. I don’t like this idea. I don’t want to get into a third project. But do I have to, even if I don’t want to?
Why did I want my own makefile target in the first place? Usually, POK is build for embedded devices and the virtualization capability is not in the main focus of the system. Libpart is a custom to the virtualization of RTEMS and is not necessary for everything else. So fusing the build of libpart into the partition target, would build it even if it is not needed. That is the case for nearly every system.
On the other hand libpok is only generated at compile time and doesn’t influence the binary. So it has no impact on the performance of the target system and a tiny compile time addition isn’t noticeable on todays systems.
After reconsidering the decision process I will try to build libpart together with the partition, without modifying ocarina. I just included the current libpart make rule in the prerequisites of the target rule in rules-partition.mk but unfortunatly it isn’t that easy, as the $+ opartor is trying to include libpart in the binary. The second target mentioned in the partition’s makefile is libpok. But as libpart depends on libpok I can’t use libpart as prerequisite for libpok. The current solution is to build libpart under the libpok target and adding the $(OBJS) as prerequisite.
I rebuild the rtems-guest example without errors and compared the nm output of a former libpart.a with the new one. It was equal. To test if the change broke something I ran make test. All test cases compiled successfully.