| Re: [cdt-dev] What exactly is CDT core build? |
My 2cent
For instance... I use "configuration and preferences" exactly the other way around :-D
On Thu, 20 Aug 2020 at 14:59, Liviu Ionescu <ilg@xxxxxxxxxx> wrote:
> On 20 Aug 2020, at 21:12, 15 knots <fifteenknots505@xxxxxxxxx> wrote:
>
> I can see that
> CBuildConfiguration uses osgi.service.prefs.Preferences to store the
> project settings.
Since I don't know the scope of CBuildConfiguration, I might be completely off topic, and in this case disregards my comment, but please be sure you preserve the distinction between configuration and preferences.
A configuration is a set of definitions specific to the project. The file(s) used to store it must be portable, in other words it should not store absolute paths or other platform specific definitions, and generally should be valid on all platforms (Windows, macOS, GNU/Linux). Configuration files can be safely stored in repositories.
Preferences are definitions specific to a platform. They can include absolute paths and other information specific to the developer or the developer environment. Preferences should not be stored in repositories, since they generally collide with other team member preferences.
I think that is not the universal definitions in CDT for preferences vs configuration. It is complicated by the fact that Preferences is an API as well as a concept - more below.
I'm getting to this stage more and more.
As an example, .project and .cproject are configuration files, and should be stored in the repository (assuming they include portable definitions), and the files in the .settings folder should generally not be saved in a repository.
I think this is an interesting point and I would appreciate some more insight on your views on this. The irony of my role is I spend all my time in Java land and end up more familiar with JDT as a user than CDT itself.
I 100% agree that if there is an absolute path in a setting it should not (generally) be checked in, equally indexer settings related to performance and scalability. But most of what I generally see checked in .settings are things like formatter preferences, codan settings, language settings and other more minor stuff.
There are those that advocate that even .cproject/.project should not be checked in - but I think this camp is mostly when team members are not all using Eclipse CDT.
I tell people to check in .cproject and .project and then no longer check them in (I always forget the git command name). This because when used across different osses/systems checking these files in creates lots of problems.
I would like this to work and I think one should check-in .project and .cproject but because it creates a lot of problems I advice to check one in, test whether importing works on a different system and then "don"t touch it"
One of the problems is that the .cproject contains ID's for
instance
<cconfiguration id="it.baeyens.arduino.core.toolChain.release.813972784">
I have no clue where the number 813972784 comes from or why it is
needed. I noted CDT to change these without me having a clue why.
Speaking about importing c/c++ projects. I never got "import
using the new project wizard" to work which is needed if you do
not check in the .project and .cproject.
Thanks for your insights.
Jonah
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev