What exactly is CDT core build?

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

What exactly is CDT core build?

15 knots
Hi all,

What exactly is core build compared to managed build? Are there any
concept papers that explain it? I found standard build [1] in the CDT
wiki.
Which packages belong to the scope of core build?

I am evaluating a path to improve cmake build support for CDT that
takes the CMakeLists.txt as the source of truth. I already did that
for managed build (cmake4eclipse), but MBS gives a project
configuration UI that is confusing to users: Lots of the input fields
simply have no effect if the project uses cmake to generate build
scripts.

Looking at the CDT code base, I found at least one discrepancy:
The CMake-project-creation wizard put a <pathentry> for the output
location into the .cproject file, but CBuildConfiguration.class
hard-codes the location to be
project.getFolder("build").getFolder(configName).
Is core build supposed to use .cproject to store the preferences any longer?

Regards, Martin

[1] https://wiki.eclipse.org/CDT/NewBuild/Standard
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham
Hi Martin,

Core build was written by Doug - he isn't active here anymore.

Jeff has the most experience with Core build AFAIK.

@Jeff, can you comment on any of Martin's questions, or direct us to the best place to find the answers?

Thanks,
Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Tue, 4 Aug 2020 at 16:28, 15 knots <[hidden email]> wrote:
Hi all,

What exactly is core build compared to managed build? Are there any
concept papers that explain it? I found standard build [1] in the CDT
wiki.
Which packages belong to the scope of core build?

I am evaluating a path to improve cmake build support for CDT that
takes the CMakeLists.txt as the source of truth. I already did that
for managed build (cmake4eclipse), but MBS gives a project
configuration UI that is confusing to users: Lots of the input fields
simply have no effect if the project uses cmake to generate build
scripts.

Looking at the CDT code base, I found at least one discrepancy:
The CMake-project-creation wizard put a <pathentry> for the output
location into the .cproject file, but CBuildConfiguration.class
hard-codes the location to be
project.getFolder("build").getFolder(configName).
Is core build supposed to use .cproject to store the preferences any longer?

Regards, Martin

[1] https://wiki.eclipse.org/CDT/NewBuild/Standard
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

15 knots
Bump?

Am Mi., 5. Aug. 2020 um 01:33 Uhr schrieb Jonah Graham <[hidden email]>:

>
> Hi Martin,
>
> Core build was written by Doug - he isn't active here anymore.
>
> Jeff has the most experience with Core build AFAIK.
>
> @Jeff, can you comment on any of Martin's questions, or direct us to the best place to find the answers?
>
> Thanks,
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Tue, 4 Aug 2020 at 16:28, 15 knots <[hidden email]> wrote:
>>
>> Hi all,
>>
>> What exactly is core build compared to managed build? Are there any
>> concept papers that explain it? I found standard build [1] in the CDT
>> wiki.
>> Which packages belong to the scope of core build?
>>
>> I am evaluating a path to improve cmake build support for CDT that
>> takes the CMakeLists.txt as the source of truth. I already did that
>> for managed build (cmake4eclipse), but MBS gives a project
>> configuration UI that is confusing to users: Lots of the input fields
>> simply have no effect if the project uses cmake to generate build
>> scripts.
>>
>> Looking at the CDT code base, I found at least one discrepancy:
>> The CMake-project-creation wizard put a <pathentry> for the output
>> location into the .cproject file, but CBuildConfiguration.class
>> hard-codes the location to be
>> project.getFolder("build").getFolder(configName).
>> Is core build supposed to use .cproject to store the preferences any longer?
>>
>> Regards, Martin
>>
>> [1] https://wiki.eclipse.org/CDT/NewBuild/Standard
>> _______________________________________________
>> cdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jeff Johnston
Hi Martin, sorry for the late reply; didn't notice this was directed to me.

Core build is relatively young and was an initiative started by Doug to simplify the build mechanism especially in the case where
the build mechanism took care of most things internally (e.g. Makefile, CMake, meson).  It was essentially still a work in progress when Doug left and he started simple
with the intention that others would modify it as needed.  My experience with it was to add meson support and allow Docker Containers to be used as targets.

Regarding Core build and .cproject, there are no set rules.  It was my understanding that Core build attempted to simplify the myriad of settings and probably why the initial
version hard-coded using the config name.  If the wizard doesn't need to store a setting, then that can be modified.

-- Jeff J.

On Wed, Aug 19, 2020 at 1:42 PM 15 knots <[hidden email]> wrote:
Bump?

Am Mi., 5. Aug. 2020 um 01:33 Uhr schrieb Jonah Graham <[hidden email]>:
>
> Hi Martin,
>
> Core build was written by Doug - he isn't active here anymore.
>
> Jeff has the most experience with Core build AFAIK.
>
> @Jeff, can you comment on any of Martin's questions, or direct us to the best place to find the answers?
>
> Thanks,
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Tue, 4 Aug 2020 at 16:28, 15 knots <[hidden email]> wrote:
>>
>> Hi all,
>>
>> What exactly is core build compared to managed build? Are there any
>> concept papers that explain it? I found standard build [1] in the CDT
>> wiki.
>> Which packages belong to the scope of core build?
>>
>> I am evaluating a path to improve cmake build support for CDT that
>> takes the CMakeLists.txt as the source of truth. I already did that
>> for managed build (cmake4eclipse), but MBS gives a project
>> configuration UI that is confusing to users: Lots of the input fields
>> simply have no effect if the project uses cmake to generate build
>> scripts.
>>
>> Looking at the CDT code base, I found at least one discrepancy:
>> The CMake-project-creation wizard put a <pathentry> for the output
>> location into the .cproject file, but CBuildConfiguration.class
>> hard-codes the location to be
>> project.getFolder("build").getFolder(configName).
>> Is core build supposed to use .cproject to store the preferences any longer?
>>
>> Regards, Martin
>>
>> [1] https://wiki.eclipse.org/CDT/NewBuild/Standard
>> _______________________________________________
>> cdt-dev mailing list
>> [hidden email]
>> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> [hidden email]
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

15 knots
Am Mi., 19. Aug. 2020 um 21:47 Uhr schrieb Jeff Johnston <[hidden email]>:

> Core build is relatively young and was an initiative started by Doug to simplify the build mechanism especially in the case where
> the build mechanism took care of most things internally (e.g. Makefile, CMake, meson).  It was essentially still a work in progress when Doug left and he started simple
> with the intention that others would modify it as needed.  My experience with it was to add meson support and allow Docker Containers to be used as targets.

Thank you for this explanation. Will have to look into the meson code
to figure out how it supports docker containers.

>
> Regarding Core build and .cproject, there are no set rules.  It was my understanding that Core build attempted to simplify the myriad of settings and probably why the initial
> version hard-coded using the config name.  If the wizard doesn't need to store a setting, then that can be modified.

I am planning to improve cmake support. I can see that
CBuildConfiguration uses osgi.service.prefs.Preferences to store the
project settings. Unfortunately o.o.s.p.Preferences does not allow to
store lists or sets of Strings which I need for cmake support. Neither
does org.eclipse.core.runtime.preferences.OsgiPreferenceMetadataStore.
So I think I am forced to store them in the .cproject somehow.

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Alexander Fedorov
Although it is not supported, the collection storage is often
implemented as "tokenizable" String. The implementation does not look
tricky if you have good separator for your values.

Regardless to what is supported by preferences you should think
carefully about where and how to store your settings.
Please don't forget the team work scenarios - your settings should be
friendly to version control.

Regards,
AF

20.08.2020 21:12, 15 knots пишет:
> Unfortunately o.o.s.p.Preferences does not allow to
> store lists or sets of Strings which I need for cmake support. Neither
> does org.eclipse.core.runtime.preferences.OsgiPreferenceMetadataStore.
> So I think I am forced to store them in the .cproject somehow.

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham
In reply to this post by 15 knots

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Thu, 20 Aug 2020 at 14:13, 15 knots <[hidden email]> wrote:
Am Mi., 19. Aug. 2020 um 21:47 Uhr schrieb Jeff Johnston <[hidden email]>:

> Core build is relatively young and was an initiative started by Doug to simplify the build mechanism especially in the case where
> the build mechanism took care of most things internally (e.g. Makefile, CMake, meson).  It was essentially still a work in progress when Doug left and he started simple
> with the intention that others would modify it as needed.  My experience with it was to add meson support and allow Docker Containers to be used as targets.

Thank you for this explanation. Will have to look into the meson code
to figure out how it supports docker containers.

>
> Regarding Core build and .cproject, there are no set rules.  It was my understanding that Core build attempted to simplify the myriad of settings and probably why the initial
> version hard-coded using the config name.  If the wizard doesn't need to store a setting, then that can be modified.

I am planning to improve cmake support. I can see that
CBuildConfiguration uses osgi.service.prefs.Preferences to store the
project settings. Unfortunately o.o.s.p.Preferences does not allow to
store lists or sets of Strings which I need for cmake support. Neither
does org.eclipse.core.runtime.preferences.OsgiPreferenceMetadataStore.
So I think I am forced to store them in the .cproject somehow.


I would recommend storing new stuff in a new file if a preference file format is insufficient - sort of like language.settings.xml in the .settings directory. Anything can be stored in the .settings directory, just preferences has a good mechanism. 

In addition to what Alexander said, there are three common ways to store in preferences more complicated things:

1- Single preference with tokens
2- Multiple numbered preferences (.e.g pref_0=value0 pref_1=value1 pref_N=2 for an array)
3- serialized xml or json

1 and 3 both are not great for version control as the store lists as a single line making diffs in version control harder than they could be.

HTH,
Jonah


 
Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Liviu Ionescu-2
In reply to this post by 15 knots


> On 20 Aug 2020, at 21:12, 15 knots <[hidden email]> 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.

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.


Hope this helps.

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham

On Thu, 20 Aug 2020 at 14:59, Liviu Ionescu <[hidden email]> wrote:


> On 20 Aug 2020, at 21:12, 15 knots <[hidden email]> 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.
 

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.

Thanks for your insights.

Jonah




_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Torbjörn Svensson
On 20/08/2020 21:29, Jonah Graham wrote:

> On Thu, 20 Aug 2020 at 14:59, Liviu Ionescu <[hidden email]> wrote:
>
>>
>>
>>> On 20 Aug 2020, at 21:12, 15 knots <[hidden email]> 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.
>
>
>>
>> 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.
>
> Thanks for your insights.
>
> Jonah


In my experience, I've always included the .settings directory in
GIT/SVN to make sure that the same settings were used for all developers
of the project.

I would like to remind everyone that files that are placed in the
.settings directory does not relate to any build configuration (or
similar concept) and needs to be handled with care.
Why do I say this?
Well, I used to work on a product that placed a file in the .settings
directory that contained some target related settings that appeared to
be fine at that time, but later on, there was a new requirement to
support different targets via different build configurations (managed
build, yes I know, but I still think it's a valid point). This ended up
being a lot messier than it had to be if we had simply avoided the
.settings file to begin with.


Kind regards,
Torbjörn

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

15 knots
In reply to this post by Jonah Graham
Am Do., 20. Aug. 2020 um 20:40 Uhr schrieb Jonah Graham
<[hidden email]>:

>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Thu, 20 Aug 2020 at 14:13, 15 knots <[hidden email]> wrote:
>>
>> Am Mi., 19. Aug. 2020 um 21:47 Uhr schrieb Jeff Johnston <[hidden email]>:
>>
>> > Core build is relatively young and was an initiative started by Doug to simplify the build mechanism especially in the case where
>> > the build mechanism took care of most things internally (e.g. Makefile, CMake, meson).  It was essentially still a work in progress when Doug left and he started simple
>> > with the intention that others would modify it as needed.  My experience with it was to add meson support and allow Docker Containers to be used as targets.
>>
>> Thank you for this explanation. Will have to look into the meson code
>> to figure out how it supports docker containers.
>>
>> >
>> > Regarding Core build and .cproject, there are no set rules.  It was my understanding that Core build attempted to simplify the myriad of settings and probably why the initial
>> > version hard-coded using the config name.  If the wizard doesn't need to store a setting, then that can be modified.
>>
>> I am planning to improve cmake support. I can see that
>> CBuildConfiguration uses osgi.service.prefs.Preferences to store the
>> project settings. Unfortunately o.o.s.p.Preferences does not allow to
>> store lists or sets of Strings which I need for cmake support. Neither
>> does org.eclipse.core.runtime.preferences.OsgiPreferenceMetadataStore.
>> So I think I am forced to store them in the .cproject somehow.
>>
>
> I would recommend storing new stuff in a new file if a preference file format is insufficient - sort of like language.settings.xml in the .settings

So IIUC you recommend for new code on CDT to *NOT* store settings in
.cproject any longer? Well, I'm fine with that.

> directory. Anything can be stored in the .settings directory, just preferences has a good mechanism.
>
> In addition to what Alexander said, there are three common ways to store in preferences more complicated things:
>
> 1- Single preference with tokens
> 2- Multiple numbered preferences (.e.g pref_0=value0 pref_1=value1 pref_N=2 for an array)
> 3- serialized xml or json
>
> 1 and 3 both are not great for version control as the store lists as a single line making diffs in version control harder than they could be.
Neither is 2): If pref_0=value0 is removed, you will see changes for
pref_1..pref_N in version control instead of just a single deleted
line.
Concerning 3) serialized xml or json: If it would be stored in
*multiple* lines, it would be more VC friendly. AFAIK,  at least Java
property files allow to store multi-line values.

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham

On Thu, 20 Aug 2020 at 16:00, 15 knots <[hidden email]> wrote:

> I would recommend storing new stuff in a new file if a preference file format is insufficient - sort of like language.settings.xml in the .settings

So IIUC you recommend for new code on CDT to *NOT* store settings in
.cproject any longer? Well, I'm fine with that.

+1
 

> directory. Anything can be stored in the .settings directory, just preferences has a good mechanism.
>
> In addition to what Alexander said, there are three common ways to store in preferences more complicated things:
>
> 1- Single preference with tokens
> 2- Multiple numbered preferences (.e.g pref_0=value0 pref_1=value1 pref_N=2 for an array)
> 3- serialized xml or json
>
> 1 and 3 both are not great for version control as the store lists as a single line making diffs in version control harder than they could be.
Neither is 2): If pref_0=value0 is removed, you will see changes for
pref_1..pref_N in version control instead of just a single deleted
line.

Yes that is a good point. There are a lot of places in Eclipse (CDT and other) that store lists as comma or semi-colon separated on one line (e.g. launch file for enabled plug-ins). These are impossible to read so I really appreciate you taking the time to consider carefully how to store this information.
 
Concerning 3) serialized xml or json: If it would be stored in
*multiple* lines, it would be more VC friendly. AFAIK,  at least Java
property files allow to store multi-line values.

Good point - in practice all the stuff that sticks XML in preferences files today stores the whole XML file in one line (using escaping). I think IMemento interface is used for that.

My guess is that most anything new these days gets stored in a json file. <-- that is not a rule, just an observation

Jonah
 

Martin
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jan Baeyens
In reply to this post by Jonah Graham

My 2cent

Op 20/08/2020 om 21:29 schreef Jonah Graham:

On Thu, 20 Aug 2020 at 14:59, Liviu Ionescu <[hidden email]> wrote:


> On 20 Aug 2020, at 21:12, 15 knots <[hidden email]> 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.
For instance... I use "configuration and preferences" exactly the other way around :-D
 

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'm getting to this stage more and more.

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
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Liviu Ionescu-2
In reply to this post by Jonah Graham


> On 20 Aug 2020, at 22:29, Jonah Graham <[hidden email]> wrote:
>
> 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 know it is complicated, and I had a lot of problems with projects that store configuration data as preferences.

But take a step back and think what (project) configuration is and how it differs from (user) preferences.

It is a pity that the documentation does not clearly make this distinction, and some plug-ins store configuration data in .settings, and then require those files to be saved in repositories.

> 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.

Sure, but I'm not sure I can explain it very well.

You should always imagine that a project is stored in a repository, and from there it is cloned by different users on different platforms (Windows, macOS, GNU/Linux).

Everything that is specific to the project (in other words the same for all users) should be considered project configuration and be stored in .cproject, and everything else that is specific for each user should be considered user preferences and be stored locally in .settings.

It is perfectly possible to add new sections in .cproject for this, but unfortunately many projects store this as preferences.

> 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.

I don't know, for me, as a non-native English speaker, the distinction between configuration and preferences is quite obvious.


Hope this helps,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Liviu Ionescu-2
In reply to this post by Jan Baeyens


> On 20 Aug 2020, at 23:31, Jan Baeyens <[hidden email]> wrote:
>
> 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"

If this happens, it is a sign of a poorly designed plug-in.

By design .project and .cproject should be portable, and ideally the plug-ins should not store non-portable definitions there.

>
> 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

random() followed by a uniqueness check.

> or why it is needed. I noted CDT to change these without me having a clue why.

CDT generally generates these IDs at project creation time and does not change them during the project lifetime (unless very special cases or rather poorly designed plug-ins).

I did some translators between CDT and other build systems (for example mBed, xPacks) and I played with these details.


Regards,

Liviu
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham
In reply to this post by Liviu Ionescu-2

On Thu, 20 Aug 2020 at 17:02, Liviu Ionescu <[hidden email]> wrote:

Everything that is specific to the project (in other words the same for all users) should be considered project configuration and be stored in .cproject, and everything else that is specific for each user should be considered user preferences and be stored locally in .settings.

It is perfectly possible to add new sections in .cproject for this, but unfortunately many projects store this as preferences.


Just for completeness - do you consider the formatter and codan setting to be stored in the wrong place in current Eclipse design? I strongly think they should be checked in as part of the project, but they are currently in .settings.

Thanks,
Jonah

 

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Liviu Ionescu-2


> On 21 Aug 2020, at 03:32, Jonah Graham <[hidden email]> wrote:
>
> ... do you consider the formatter and codan setting to be stored in the wrong place in current Eclipse design? I strongly think they should be checked in as part of the project, but they are currently in .settings.

I'm not sure I understand exactly what you mean, since I remember that for formatting I have an external xml that I store explicitly in my main projects, and I load it manually in the Eclipses I use for development.

As for code analysis, I remember I evaluated it several years ago, and did not seem ready for prime time, so I have close to zero experience with it.

But, to answer your question, to me they look like configurations, not preferences, so yes, they should not be stored in .settings.


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham
👍 Thanks for all your input. Hopefully it helps Martin in his short term goal and all of us long term.

My conclusion is simply all settings (configuration or preferences) should be in human readable format in a way that works nicely with version control. This is because different teams and individuals have different needs on what should be checked in.

I believe that statement is not new or controversial idea. 

Regards, 
Jonah 

On Fri., Aug. 21, 2020, 04:39 Liviu Ionescu, <[hidden email]> wrote:


> On 21 Aug 2020, at 03:32, Jonah Graham <[hidden email]> wrote:
>
> ... do you consider the formatter and codan setting to be stored in the wrong place in current Eclipse design? I strongly think they should be checked in as part of the project, but they are currently in .settings.

I'm not sure I understand exactly what you mean, since I remember that for formatting I have an external xml that I store explicitly in my main projects, and I load it manually in the Eclipses I use for development.

As for code analysis, I remember I evaluated it several years ago, and did not seem ready for prime time, so I have close to zero experience with it.

But, to answer your question, to me they look like configurations, not preferences, so yes, they should not be stored in .settings.


Regards,

Liviu

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jan Baeyens
In reply to this post by Jonah Graham

Wrongly send to Jonah only, now to the list. :-(

Op 21/08/2020 om 2:32 schreef Jonah Graham:

On Thu, 20 Aug 2020 at 17:02, Liviu Ionescu <[hidden email]> wrote:

Everything that is specific to the project (in other words the same for all users) should be considered project configuration and be stored in .cproject, and everything else that is specific for each user should be considered user preferences and be stored locally in .settings.

It is perfectly possible to add new sections in .cproject for this, but unfortunately many projects store this as preferences.


Just for completeness - do you consider the formatter and codan setting to be stored in the wrong place in current Eclipse design? I strongly think they should be checked in as part of the project, but they are currently in .settings.

I have worked a couple of years as a "development shop architect". This kind of questions were my daily bread and butter. So here are my initial 2 cent

I'd say the file type (cp1252,utf 6, ...) should be "one way or another" controlled by eclipse in case of version control.

Formatting and version control is a really painfull combination.
The formatting settings should be optionally enforced to be checked in. Basically if you work as a team on the same code you should not have to worry about the formatter changing the code all the time. On the other hand, when you import some code from some repository you likely want to stick to your formatting.

The only good way I see to implement something like this is that you would have a "stored format" and a "gui format". Given the complexity of reformatting and all the trouble I have seen with the current formatter I do not expect to see something working like this in my lifetime.
Workarounds for these are checking in exported settings or installing via oomph.

I don't know enough about codan to make a strong statement. My first thought: I would think not.

As to .settings.

I'm always reluctant to check in .XXX stuff. I never considered checking in .settings. I suppose I'm not the only one.
On top of that I suppose that if you do not use project specific formatting settings there will not be any formatting settings there.

And -as I stated before- generated unique numbers and version control just don't mix nice. For instance I see 2 ID's in my org.eclipse.cdt.core.prefs

...
environment/project/it.baeyens.arduino.core.toolChain.release.813972784.1896377334/appendContributed=true
environment/project/it.baeyens.arduino.core.toolChain.release.813972784.614502937/A.ALT_SIZE_COMMAND/delimiter=;
...

Jantje

Thanks,
Jonah

 

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
Reply | Threaded
Open this post in threaded view
|

Re: What exactly is CDT core build?

Jonah Graham
> The formatting settings should be optionally enforced to be checked in. Basically if you work as a team on the same code you should not have to worry about the formatter changing the code all the time. 

I strongly agree with this statement! 

> And -as I stated before- generated unique numbers and version control just don't mix nice. 

I really wish someone could explain this design rationale, I suspect the details and importance of it have been lost in history now.

Jonah
~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 21 Aug 2020 at 07:57, Jan Baeyens <[hidden email]> wrote:

Wrongly send to Jonah only, now to the list. :-(

Op 21/08/2020 om 2:32 schreef Jonah Graham:

On Thu, 20 Aug 2020 at 17:02, Liviu Ionescu <[hidden email]> wrote:

Everything that is specific to the project (in other words the same for all users) should be considered project configuration and be stored in .cproject, and everything else that is specific for each user should be considered user preferences and be stored locally in .settings.

It is perfectly possible to add new sections in .cproject for this, but unfortunately many projects store this as preferences.


Just for completeness - do you consider the formatter and codan setting to be stored in the wrong place in current Eclipse design? I strongly think they should be checked in as part of the project, but they are currently in .settings.

I have worked a couple of years as a "development shop architect". This kind of questions were my daily bread and butter. So here are my initial 2 cent

I'd say the file type (cp1252,utf 6, ...) should be "one way or another" controlled by eclipse in case of version control.

Formatting and version control is a really painfull combination.
The formatting settings should be optionally enforced to be checked in. Basically if you work as a team on the same code you should not have to worry about the formatter changing the code all the time. On the other hand, when you import some code from some repository you likely want to stick to your formatting.

The only good way I see to implement something like this is that you would have a "stored format" and a "gui format". Given the complexity of reformatting and all the trouble I have seen with the current formatter I do not expect to see something working like this in my lifetime.
Workarounds for these are checking in exported settings or installing via oomph.

I don't know enough about codan to make a strong statement. My first thought: I would think not.

As to .settings.

I'm always reluctant to check in .XXX stuff. I never considered checking in .settings. I suppose I'm not the only one.
On top of that I suppose that if you do not use project specific formatting settings there will not be any formatting settings there.

And -as I stated before- generated unique numbers and version control just don't mix nice. For instance I see 2 ID's in my org.eclipse.cdt.core.prefs

...
environment/project/it.baeyens.arduino.core.toolChain.release.813972784.1896377334/appendContributed=true
environment/project/it.baeyens.arduino.core.toolChain.release.813972784.614502937/A.ALT_SIZE_COMMAND/delimiter=;
...

Jantje

Thanks,
Jonah

 

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
[hidden email]
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
12