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

[Sergey Kalinichev]

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

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.


- Sergey


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


On Jan. 9, 2015, 2:53 p.m., Sergey Kalinichev wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121777/
> -----------------------------------------------------------
> 
> (Updated Jan. 9, 2015, 2:53 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/compilerprovider/compilerfactories.h 00042fb 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerfactories.cpp 8d47690 
>   languages/plugins/custom-definesandincludes/compilerprovider/compilerprovider.cpp 3643e78 
>   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 
>   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/kcm_widget/compilerswidget.ui 0c90cee 
>   languages/plugins/custom-definesandincludes/kcm_widget/projectpathswidget.ui 3e413b3 
> 
> 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/033bfee2/attachment-0001.html>