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

Wed Jan 21 14:05:45 UTC 2015

> On Jan. 16, 2015, 2:40 a.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.
> 
> Kevin Funk wrote:
>     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.

>Adding more options doesn't make it better.

Maybe, but it makes it more flexible. Actually this patch doesn't add additional options. Before you could choose: "gcc", "clang". Now: "gcc c99", "gcc c++11" e.t.c. That's the only difference.

 >The user doesn't know what he's configuring. Is he configuring the compiler used to built his project or the internal parser?

Are there really such users? I mean, the page is called "Custom defines and includes". Also there is a text label explaining what it's for. How could anyone confuse it with a compiler used for building the project?
Actually it'd be great to use the same compiler for both (project building and parser), but it's not always possible.

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

I wouldn't say so. Yes, due to it bugs oldcpp can't parse all plain C projects. But this setting affects standard include directories/macros used by the oldcpp, so it doesn't ignore this feature.

- Sergey

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

On Jan. 19, 2015, 2:38 p.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, 2:38 p.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/20150121/32145674/attachment.html>