You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you may know the latest version of Sloeber allows you to share you configuration settings (like the Arduino board and compile settings) in a Sloeber.cfg so you can put the configuration information in a version control tool.
This way when you extract a project from a version control tool (or share via zip) Sloeber knows the board and compile settings.
I tried to store stuff in a OS independent way so it is compatible over OS so ports are not in the Sloeber.cfg file.
In other words the Sloeber.cfg is supposed to contain all the OS independent data for all the configurations you selected.
That is one Sloeber.cfg for one project with all shared configurations.
Another option is to have a Sloeber.[configuration name].cfg file per configuration.
Both have their pro's and cons and I can't come to a conclusion what should be the best approach.
So I decided to do a poll and see what you guys think.
Feel free to comment and elaborate on your perception.
One big advantage I see on the Sloeber.[configuration name].cfg is that the selection whether you want to share it or not could simply be sharing the file or not.
Let me explain.
Currently Sloeber store the configuration data in a .sproject file (next to the .project file )
Sharing that file means sharing all you configurations. For a team, they will end up with everybody having everyone's configuration; resulting in configuration name conflicts and way to many changes to the file.
Therefore I created the Sloeber.cfg file which is only created when it is turned on in the project properties for that specific configuration. That file contains a subset of the info in Sloeber.cfg (basically only the selected configs and OS independent configuration data)
When Sloeber opens a project the .sproject is read in memory and then the sloeber.cfg which makes that sloeber.cfg overrules .sproject files allowing changes to arrive from version control. (If I remember correctly the same happens when sloeber.cfg changes)
If Sloeber would create a Sloeber.[configuration name].cfg file per configuration the selection of which configs to share could be done at the version control level (simply share the file or not)
Maybe it is even possible to add a username to the OS dependent keys or store them elsewhere; so I can get rid of the sloeber.cfg file.
Anyway input is appreciated.
Jantje
How would you prefer the Sloeber approach to storing OS independent configuration specific information
I prefer one sloeber.cfg file containing all the configurations
100%
I prefer a Sloeber.[configuration name].cfg file per configuration
0%
I have no idea what you are talking about
0%
I don't care
0%
others (please elaborate in the discussion section)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
As you may know the latest version of Sloeber allows you to share you configuration settings (like the Arduino board and compile settings) in a Sloeber.cfg so you can put the configuration information in a version control tool.
This way when you extract a project from a version control tool (or share via zip) Sloeber knows the board and compile settings.
I tried to store stuff in a OS independent way so it is compatible over OS so ports are not in the Sloeber.cfg file.
In other words the Sloeber.cfg is supposed to contain all the OS independent data for all the configurations you selected.
That is one Sloeber.cfg for one project with all shared configurations.
Another option is to have a Sloeber.[configuration name].cfg file per configuration.
Both have their pro's and cons and I can't come to a conclusion what should be the best approach.
So I decided to do a poll and see what you guys think.
Feel free to comment and elaborate on your perception.
One big advantage I see on the Sloeber.[configuration name].cfg is that the selection whether you want to share it or not could simply be sharing the file or not.
Let me explain.
Currently Sloeber store the configuration data in a .sproject file (next to the .project file )
Sharing that file means sharing all you configurations. For a team, they will end up with everybody having everyone's configuration; resulting in configuration name conflicts and way to many changes to the file.
Therefore I created the Sloeber.cfg file which is only created when it is turned on in the project properties for that specific configuration. That file contains a subset of the info in Sloeber.cfg (basically only the selected configs and OS independent configuration data)
When Sloeber opens a project the .sproject is read in memory and then the sloeber.cfg which makes that sloeber.cfg overrules .sproject files allowing changes to arrive from version control. (If I remember correctly the same happens when sloeber.cfg changes)
If Sloeber would create a Sloeber.[configuration name].cfg file per configuration the selection of which configs to share could be done at the version control level (simply share the file or not)
Maybe it is even possible to add a username to the OS dependent keys or store them elsewhere; so I can get rid of the sloeber.cfg file.
Anyway input is appreciated.
Jantje
1 vote ·
Beta Was this translation helpful? Give feedback.
All reactions