I have a firmware that supports two builds, stm32f series and stm32g series. To ease selection during deployment, Is it feasible to have one firmware build for both?
The firmware is using HAL from stm and building them into one will have a conflict in the function names ,variable names, etc.
One option that I am trying is to rename all the HAL functions and other variable or types to each specific MCU, and have them in a wrapper so I can include both.
Is there any other way to approach this?
Your idea seems quite possible, but a lot of work. On multiple occasions I have made builds of software that are compatible with the same MCU on different PCBs, so you are just taking this to another level.
From a project point of view, you are making the purchasing department's job easier by making the engineering department's job a lot harder. You will need to make an estimate of whether this is worth it. In this time of semiconductor shortages, it might be.
The first thing I would consider is how much application code you have that is common to both MCUs. If you have enough flash to store not only a copy of drivers for both chips but two whole applications, then the easiest thing to do would be to program two complete builds. A tiny bootloader can then detect the processor ID and jump to the appropriate block. You can have a final build step that combines these into a single binary for production.
If you can't do this, then the next thing I would look at is trying to modularize your drivers and build them separately. You have already identified that you will have a problem with duplicate function and variable names, but you will also have to compile with separate compiler flags, especially the macro definitions.
Many linux kernel drivers contain the same function names, but all the functions are static so they don't go into the symbol table. Pointers to these static functions are assigned into members of a struct, and this struct is how the rest of the kernel accesses the drivers. You could do something similar. Write simple wrapper functions for each of the drivers that use your own types and can be called by only including the common header for the wrapper and none of the STM32 HAL headers. Make a separate wrapper function for each MCU that uses the same prototype. Put these functions in a struct. You will then need to compile and use some fancy linker flags to hide all the symbols on the symbol table apart from that struct. This way you can link both sets of drivers without having duplicate symbols.
If you don't want to do this then you will have to edit the source of the HAL code. I would only do this as a last resort, and do everything you can to automate it. Write some script that does a search and replace for all identifiers and either add static to their declaration, or else add a prefix to their name. Try to make the script in such a way that when there is a new release of the HAL it will still work (ie: don't just use a diff patch). Remember that even after you have edited the code you will still have to compile the two drivers with different flags, but once you have compiled you will be able to link them together.