Review Request 121777: Make it possible to change language standard for the parser

[Kevin Funk]

> On Jan. 15, 2015, 10:40 p.m., Kevin Funk wrote:
> > I just briefly skimmed the patch. I think we need to overthink this completely:
> > 
> > What do we actually want?
> > - We'd like to be able to select the language standard for our *internal* parser.
> >   - This has nothing to do with binaries installed on the system
> >   - This has nothing to do with the specific compiler either (MSVC, GCC, ...)
> > 
> > Proposal:
> > - Add this setting to a language-specific settings page instead. I.e. a "C/C++/Obj" settings page
> >   - I already have multiple other ideas that I could add to this page afterwards
> >     (like making our auto-complete options configurable, for instance whether to add 'override' to a virtual function overload, etc.)
> > 
> > So in fact I'm proposing to move the "language standard" feature directly to kdev-clang instead. 
> > 
> > Opions?
> 
> Sergey Kalinichev wrote:
>     >Add this setting to a language-specific settings page instead. I.e. a "C/C++/Obj" settings page. So in fact I'm proposing to move the "language standard" feature directly to kdev-clang instead. 
>     
>     There are a couple of reasons, why it's IMO not very good:
>     a) There is no such page yet.
>     b) The oldcpp can use that standard feature too. Actually I've seen a bug report about not configurable include directories (i.e. c++11 only)
>     c) Even if we do that. Then we have to move compiler setting to that page too. Otherwise  it'd be inconvenient to select compiler on one page and standard on another. 
>     d) Also, is this "C/C++/Obj" settings page per project? If it's project wide, then ok, otherwise it won't work. As language standard can be set per project.
>     
>     So I'm suggesting to leave it as is. And give it more thinking when we finally get rid of oldcpp plugin.
> 
> Milian Wolff wrote:
>     a) the page can be created
>     b) oldcpp is not supporting different standards anyways, and will die sooner or later. so thats not an argument
>     c) this is a valid point we need to figure out how to handle
>     d) also true
>     
>     anyhow, any comments to what I said? simplifying it all by letting the user specify the command line?
> 
> Sergey Kalinichev wrote:
>     I don't know. Obviously not all users know what commands to pass. Also it's simple to misspell the options.
>     And I think that auto-detection feature still makes sense, as in most cases users want it to work out of the box without spending time on configuring compilers.

c) True. But right now the Compiler Settings page is confusing already. Adding more options doesn't make it better. The user doesn't know what he's configuring. Is he configuring the compiler used to built his project or the internal parser?
We need to design that UI carefully, as it's already starting to become confusing IMO.
d) Yes. I was thinking about making this project-specific.

e) Now that this feature would be added to the IADM settings page => oldcpp would ignore that settings => confuses users as well.

Honestly, I'm unsure how to handle all this, need to think about it more.


- Kevin


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121777/#review74110
-----------------------------------------------------------


On Jan. 19, 2015, 10:38 a.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121777/
> -----------------------------------------------------------
> 
> (Updated Jan. 19, 2015, 10:38 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Repository: kdevelop
> 
> 
> Description
> -------
> 
> Now we can choose different language standards for computing standard include directories/defined macros. 
> Also this feature is very useful for the kdev-clang plugin (Now it's possible to parse plain C projects).
> 
> 
> Diffs
> -----
> 
>   languages/plugins/custom-definesandincludes/kcm_widget/compilerswidget.ui 0c90cee 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.cpp 5b34e75 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.ui 06a6c51 
>   languages/plugins/custom-definesandincludes/compilerprovider/msvccompiler.cpp fcd9db7 
>   languages/plugins/custom-definesandincludes/compilerprovider/settingsmanager.cpp 229f456 
>   languages/plugins/custom-definesandincludes/kcm_widget/compilerswidget.cpp aebbf5a 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.h 00042fb 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.cpp 8d47690 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp 24d711d 
>   languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.h 079b78d 
>   languages/plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp bc99d8d 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompiler.h 3627ebd 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompiler.cpp 0bf6a44 
>   languages/plugins/custom-definesandincludes/compilerprovider/icompilerfactory.h 3849bcb 
>   languages/plugins/custom-definesandincludes/compilerprovider/msvccompiler.h a59a6b7 
> 
> Diff: https://git.reviewboard.kde.org/r/121777/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sergey Kalinichev
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20150119/d3ef30be/attachment.html>