Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] What exactly is CDT core build?
> 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 <jan@xxxxxxxxxx> 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 <ilg@xxxxxxxxxx> 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
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top