Open satur9nine opened 3 weeks ago
@armink any thoughts on this?
These version number information seems to be necessary, and optimization is not recommended
I agree that some system to track the version of product HW/SW version is necessary for most embedded systems but for example my company has been using CmBacktrace for many years but we already have our own version number mechanism and prefer not to have a duplicate system, thus it is not necessary for us and probably many other users. CmBacktrace works very well without version number tracking mechanism but your choice to take the PR or not.
You can try to change CMB_USING_FIRMWARE_INFO
to CMB_NOT_USING_FIRMWARE_INFO
, so that everyone can upgrade without feeling.
Then, you need to check whether the program works properly when this macro is turned on and off.
Why not have a weak symbol cm_version_printinfo
which resolves to a blank function if internal version info is disabled or a full function doing the output when enabled. If a user has its own mechanism they simply write their own function of that name without marking it as a weak symbol, thus replacing that function at link time.
Also, why have these version strings live inside of RAM buffers in the first place?
Why not have a weak symbol
cm_version_printinfo
which resolves to a blank function if internal version info is disabled or a full function doing the output when enabled. If a user has its own mechanism they simply write their own function of that name without marking it as a weak symbol, thus replacing that function at link time.Also, why have these version strings live inside of RAM buffers in the first place?
Both good points, I can explore making these suggested changes.
Many projects already have another mechanism for getting firmware info or want to save RAM and do not need firmware info of CmBacktrace.