Re: KDevelop syntax parser is barely usable

Axel Kellermann <[email protected]>
Newsgroups gmane.comp.kde.users.kdevelop
Message-ID <[email protected]>
I'm not sure if I experience exactly the same problems as Steve and
Aleksey, but the symptoms seem similar enough that I feel I have to
chime in.
One of the largeish projects I occasionally work on is a cmake-based
C/C++ library with quite a deep directory structure and a ton of C/C++
and Python source files. Like in Steve's case, stability is not an issue
for me. Since the switch to clang I haven't had a single crash in the
parser. But at the same time kdevelop's parser seems to consistently
miss some of the projects header files, macros, templates, and function
declarations. I'm pretty sure the project isn't misconfigured, as
multiple people work on it on multiple platforms and with a variety of
IDEs, and I never heard complaints about parsing problems.
What's really weird is that only kdevelop installed via my systems
package manager seems to be affected (currently kdevelop 5.3 on Arch).
If I build kdevelop myself via kdesrc-build, the parsing seems to work
like a charm. At least all of the files I know of that previously made
trouble are processed correctly with my own build. Could that fact help
in pinpointing the trouble we seem to have? If so, what info could I
provide to help with that?

Axel

On 07.11.18 12:57, Sven Brauch wrote:
> Hi,
> 
> On Wednesday, 7 November 2018 12:11:12 CET Steve the Fiddle wrote:
>> The problem may be in part, due to
>> Audacity now making more use of C++11, and a little C++14, with more
>> templates and broader use of "modern" C++ idioms.
> 
> FWIW, this is almost always a setup problem, usually include paths and/or 
> preprocessor defines not being set up correctly. For CMake, KDevelop is very 
> good at setting this up automatically, for automake much less so.
> 
> If include paths, compiler flags and definitions are set correctly, KDevelop's 
> parser will be very close to perfect, since it uses clang behind the scenes. 
> It doesn't matter how complex your template code is.
> 
> Performance is a different topic, but correctness is very good these days.
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEYn5WSOB+DwkxyV8BzUf1wbSh1A4FAlvjXZkACgkQzUf1wbSh
1A5a9hAAox1YZ4SN0ZjqThIkInK8Y1i3DZltaUxNltyW67j6sROC7gvIFjsIC+A7
S0xkIV0W6dCvKJO8rs3kIrncyMd+iji+TvkPJCQiVRCLV00OJ6ez/RNrHAwemOgj
A8frotVwf24+cWMhtUCodSJkajQng9HdY+xwVfh7WyCbfEavSW8/rIqDl4Mk4yTH
ECfgWvfrnbOzYVUPULth2DmAMlliOa4GMa2Fz40f93l2BFoEfqAXjlvEnx1NOOwH
g6+3VHSAghC30ceUXCGIhMci4zGvN5iFpaWTHS0s4nwNWNt9PFJ+7Y5V2aEK5/V+
aDbUEI4wApgX+rJjAW0EjdVVLYB0pQM0qmAGHV6XXJPI/LEeYPIdnl6kIXl6fPJD
w+PrNgPFsQlyGNhtKUERavfRuORpEUsPlVr9d7QLxw2Y20rut93tUYW4s9EkI0D7
9m+bkjD3teIOs5Tk2mz5O8T3+cQJAkh9zcM3xTfk8VQW+bXDKZKN+zU6KmX59IU/
4wYa1e/kcR3yPUXiUUy4wSRStAQjSZlnhrdav8OyEPSiuNxYlcjNOhkLwLCAFC23
EJqE/mMFAsmdw22LtVBHqoNaUPtRpM28cPjrsf7x+hTVXgmQA5oSmXAJPFuaoJlp
C6Gz4GaO4brJcKIlL9rmUWUjdN5+O9UxsojtsMPlWfKypvwRZMk=
=7F93
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.