Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Language Settings

I have 2 concerns about discontinuing Paths&Symbols tabs and replacing with "Preprocessor Include Paths, Macros, etc.". One is that currently P&S has some functionality that PIPME does not. Namely, "Export" button and the one that you mention that the entries need to be propagated to MBS to be used during the build for managed projects. And "Add to all configurations/languages" options. If that is done in PIPME P&S tabs are unnecessary.

The second concern is about UI. As far as usability, is Paths&Symbols presentation of Includes/Symbols/Libraries in separate tabs better from end user point of view?

Thanks,
Andrew



On Wed, Jul 31, 2013 at 8:01 PM, kesselhaus <kesselhaus@xxxxxxx> wrote:
Am 30.07.2013 09:04, schrieb Christian Walther:

Andrew Gvozdev wrote:
Both "C/C++ Build" > "Settings" and "Paths and Symbols" represent settings from MBS. If you add/edit entries in either one they end up in the toolchain definition supplied by cdt.managedbuild plugin. "Paths and Symbols" also would show read-only entries captured by older scanner discovery ("C/C++ Build" > "Discovery Options").

The "C/C++ General" > "Preprocessor Include Paths, Macros etc." is cdt.core. It combines those from MBS, new scanner discovery and also UI for adding user entries. It does not need managedbuild plugin and so can be used with CDT builder which does not use MBS.

I agree that it is confusing. What about moving  "Paths and Symbols" under "C/C++ Build" and renaming it to "MBS Paths and Symbols"? Would it at least alleviate the confusion?
That sounds good. I was under the impression that "Paths and Symbols" was CDT core (independent of MBS) as well - at least I also see it in non-MBS projects - but if it is as you say then that sounds sensible.
As I remember the discussions about the "Preprocessor Include Paths, Macros, etc", it was thought of as an replacement of the "Paths&Symbols".
I think P&S was based on ScannerDiscovery, while PIPME should be based on new LanguageSettingsProviders.


However, if as you suggest in response to kesselhaus by

This is something that would be needed to be added to managed build. Could you file a bug for that?
a flow of settings from "Preprocessor Include Paths, Macros etc." to the MBS makefile generator is implemented, would there even be any purpose left for "Paths and Symbols" (apart from its "Source Location", "Output Location", and "References" tabs, which don't seem to belong there anyway) and its programmatic equivalent, "External Settings Providers"?
Not sure, if we really need all three, as I already said, I remember from the history, that the PIPME was thought of as replacement.

In PIPME you have providers by compiler/toolchain which should be filled automatically by the MBS, or for a makefile project, kept empty.
If you add User Entries in the PIPME, this should be queried by the MBS compiler/toolchain, and added to C/C++ Build pages for e.g. -I, -l/-L, -D/-U
And the other way around, if you add to C/C++ Build -I, -l/-L, this should be reflected/synchronized to the PIPME Include Paths, Library Paths and Libraries and Macros, where actually the MBS toolchain can handle to add/remove the compiler switches for each.


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev


Back to the top