There is no easy way for non hard core devs IMHO to do the following for global variables:
1) Move the variables from one PC/MAC to another.
2) Backup the global variables as you want to test a new C::B install and then later add the global variables back.
You can manually modify the config or copy/paste the data that you have saved somewhere or potentially use the cb_share_config.exe to save/update the info, but this is time consuming when testing or having to change setups for dev purposes.
Also at the same time as adding the export/import it would be very nice to add a save button as the config is not updated until you cleanly exit C::B, but if C::B crashes due to changes you are working on then you have to enter the variables again. Sometimes you want to change a variable and test it before saving, so auto saving on clicking on the "OK" button is not a good idea as then people will request that the auto save be disabled.
Example of what the dialog could look like is attached.
P.O.C updated files are attached.
This is my global variables used in my local CB source tree build that I have exported and imported using the attached files:
Last edit: Andrew Cottrell 2022-01-30
Are you aware that you can save and share/load literally any type of setting using the cb_share_config tool? It ships with C::B. There is no need to integrate this into the core. Because then you should integrate saving dedicated settings in many places which completely clutters such functionality.
In my request I wrote "or potentially use the cb_share_config.exe to save/update the info".
My proposal would be to automise the cb_share_config tool using the command line such that you can call it with specific parameters to dump current settings. Then you could embed it a s tool and save whatever you want at any time.
With my POC and a number of other ticket changes with some that may get rejected I can build CB for either win32 or win64 using a single batch file, currently one config file and manually changing the GCC compiler from C:\mys64\mingw32 to/from C:\mys64\mingw64. Currently I manually change the batch file to swap between either 32 or 64 builds, but this will change in the next day or two as I will parameterize the option.
The following is the relevant batch file snippets for the build that are used to change between win32 and win64 CB builds:
NOTES:
1) The CodeBlocks_wx31_64.workspace dependent project files have been modified for the updated/new global environment variables.
2) The new "--variable-set" parameter changes the global variable set used by the batch build. I expect that you will reject this, so if you think it will be allowed into the trunk I will create a ticket for it.
3) I still need to manually change the gcc compiler settings from 32 to 64 bit settings. I know this can be effectively done via the personality parameter, but keeping the two configs in SYNC during the dev/build/change/update process IMHO will not be easy and is prone to problems cropping up. I need to think how this process can be streamlined if possible to ensure that the dev does not go bananas having to keep two config files up to date and in sync.
4) I have also got wxWidget building via a similar method w.r.t. changing a BUILD_BITS from 32 to 64.
5) I have been working on removing the batch build GUI dialog, but it is not working yet.
6) Once all of the bits come together and flow correctly I hope that building a windows CB release can be done via a CI process. So far spent 9 months on this with I guess about 50% of my time spent dealing with trying to get patches into the trunk or updating files that are banked up due to dependent changes that are in tickets that are waiting for someone to look at the patch in the ticket.
Have a look at this https://github.com/bluehazzard/codeblocks_sf/tree/rework/move_global_var_diag_to_src%2F1
here i have reimplemented the user var dialog, to add a save button, because i really hate that there is no cancel button in this dialog. I think it is more user friendly to have a "save" and "cancel" button....
I will make a official ticket an patch after i have removed the auto words in the code
@bluehazzard, your new xrc file has
<minpanesize>property for wxSplitterWindow, it should be changed to<minsize>so the XRC works OK (see wxWidgets XRC specification and commit [r12685]).EDIT: used code tags to avoid XML garbage.
Related
Commit: [r12685]
Last edit: Miguel Gimenez 2022-01-31
Latest patch attached. The patch also includes increasing the number of user variables from 7 to 8 so the GUI looks nicer.
So, to come a step further here:
I think you are missing that you can easily specify the configuration file you want to use for C::B, thus, you can have many complete different configs for C::B. That also means, you can easily have misc. sets / options for 32 or 64 bit. So this functionality you are seeking is already present.
Could you clarify again why exactly you want to import/export global var sets (only)? Because (for example) the -m32 an -m64 switch of the compiler could raise other conflicts...?!
I am asking seriously to understand better what is actually missing that you are trying to solve.
I can clarify till the cows come home, but have you tried to understand the following:
Fixed by [r13218], [r13224] and [r13245].
Related
Commit: [r13218]
Commit: [r13224]
Commit: [r13245]