Versionize parts of codeblocks configuration

[teto]

Hi there,

I am using codeblocks (nightlies) on several computers (mainly linux) and up to now  everytime I had setup codeblocks manually. With the increased number of customizations, I would like to versionize my configuration with git. Problem is some elements may differ between computers and as far as I understand, all parameters are set in one configuration file. Is there a way to split my configuration among different files ? I understand it may be complex but for instance, if only I could put colorschemes in a specific folder/different files (apparently my colorschemes are all contained within ~/.config/codeblocks/default.conf). that would be neat already.

Anyone doing so already ?

Cheers

[oBFusCATed]

I doubt. But I suppose it won't be that hard to extend the config manager to store certain subkeys in different files.
So patches welcome:)

[MortenMacFly]

Do you know about the tool cb_share_config? It allows you to backup and restore parts of the configuration... Maybe a command line interface to automise this would be nice .

[Jenna]

On linux you might be able to use sed from inside a script.
But besides this, it might be useful in some cases to split the config-file in smaller parts (configurable ?).
This could also enhance robustness, because if something goes wrong while saving (we have seen this already), not everything configured by the user is lost.

[teto]

I know of cb_share_config and that's what I used to transfer my colorscheme since manual editing is error prone. It's a clear & good tool.
Being able to merge different config parts through a scripting interface for cb_share_config may do the trick (I don't change my settings much) but everytime you change a setting of interest, you will need to re-export manually the parts you want to versionize (bothersome).
If you have settings in different files by design, then it becomes more straightforward.
I can understand that it may not be worth to put compiler and linker options in different files but seeing the colorschemes in default.conf while every editor out there put them in files under a "colorschemes" folder really surprised me.

This could also enhance robustness, because if something goes wrong while saving (we have seen this already), not everything configured by the user is lost.

Not only that but I also noticed that codeblocks saves settings on exit, which is quite annoying when crashing (as I use nightlies it happens) or using several instances in parallel (the last instance to exit overrides all the modifications made from other instances).

[MortenMacFly]

but seeing the colorschemes in default.conf while every editor out there put them in files under a "colorschemes" folder really surprised me.

Yes, it might not have been the best way to do it.

or using several instances in parallel

Well you shouldn't do this with a common personality. In fact, the concept of personalities is there for this to work reliable.

You can run C::B with the personality parameter and thus, all settings will be in a file/folder for the specific personality. This will also avoid to overwrite parameters.

But hey - that's a problem all applications have that can run in parallel: The last app closed will dominate the settings. I don't see an easy way to avoid it because otherwise you've to consider conflicts (what if instance "A" change parameter "X" to "foo" and instance "B" to "bar"?). That's why you have to enable the options to allow instances in parallel, btw.. Again: To avoid that, use different personalities.

[teto]

A first problem of saving at exit (even with a single instance) is when you crash (same for project settings): configuration is lost. Flushing configuration to disk once exiting hte settings dialog would solve that.

As for multiple instance, once you know how it works, you can deal around it. For the sake of the argument, I imagine you would need a client/server architecture that notifies changed settings for the multiple instance cases. I understand it is not worth the effort.

[oBFusCATed]

You can run C::B with the personality parameter and thus, all settings will be in a file/folder for the specific personality. This will also avoid to overwrite parameters.

I don't think this is 100% correct. For sure the installed plugins are shared by different personalities.
The new option that allows one to use totally different config/user folder is the way to go if one needs 100% separated config files.