if modify the following line
set(FBSTRING_PLUGIN_VERSION "1.0.0.0")
in file
firebreath\projects\{ProjectDir}\PluginConfig.cmake
then run "prepxxx.cmd" or rebuild the solution directly, it could modify the version correctly, but if "PluginConfig.cmake" be modified, the solution and project files will be recreated too, all of the configuration for the solution and the projects will be discarded. if this is a complicated solution, and you have to reconfig for all of these every time, it will make people maddening!
is there better way to do this?
I believe you asked this question on the firebreath-dev list; I hope you weren't expecting a different answer here, because I wrote FireBreath and I can pretty much guarantee that any other answer will be an ugly, ugly hack.
FireBreath uses CMake, and CMake is designed so that you regenerate your project and solution files on the fly. There is very very little that you can customize on the solution or project that you can't set up correctly with cmake. The correct fix for this is to figure out how to do the things you are currently doing by hand with your solutions and do them in the CMakeLists.txt and Win/projectDef.cmake files.
If you still refuse to accept this answer, the only other way would be to find all the places where FireBreath applies those properties and change them by hand in the build directories. A quick grep shows me that it is used to customize these files:
gen_templates/config.hgen_templates/firebreathWin.rcMac/bundle_template/Info.plistAnd of course you'll need to do a bit more looking because it also gets split up and used as FB_VERSION_MAJOR, FB_VERSION_MINOR, FB_VERSION_PATCH, and FB_VERSION_BUILD
Any of these variables may be used in multiple places.
Of course, also note that if you ever update your firebreath codebase you're likely to end up triggering cmake again if there were any changes to the firebreath cmake files. As long as you don't care about ever getting bugfixes, security improvements, or about building on other machines, I suppose you could take this approach.
If I were you, I'd really think about just fixing your cmake files so you don't have to change the project by hand... every case I know of that someone has tried to ignore that advice has ended badly.