Reporting back, both repositories rustc2duchain and kdev-rust don't compile or recent ArchLinux. Incompatible versions of kde and rustc. As I have no idea about KDESDK and no time to investigate it, I find it unusable for now.
CMake Error at CMakeLists.txt:22 (find_package):
Could not find a configuration file for package "KDevPlatform" that is
compatible with requested version "4.90.91".
The following configuration files were considered but not accepted:
/usr/lib64/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
/usr/lib/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
/lib64/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
/lib/cmake/kdevplatform/KDevPlatformConfig.cmake, version: 1.7.3
Well you need to have a recent version (here: 5.0) of kdevplatform installed. kdevplatform (shell, language agnostic infrastructure, vcs plugins, etc. pp.) is a set of libraries KDevelop is based on.
Get kdevplatform from:
git://anongit.kde.org/kdevplatform
Install kdevplatform, kdevelop, kdev-rust, etc. into the same install prefix (-DCMAKE_INSTALL_PREFIX=/foo) and you should be fine.
Great news for developers to get better syntax highlighting, but another nail in the coffin for gcc, sadly.
This exact topic notoriously came up last year where emacs wanted to use exported gcc datastructures to highlight code. This proposal was disallowed by rms sticking so dogmatically to his core values that one GNU project ended up not being able to interact with another, for fear of proprietary vendors doing so.
While I fully understand the technical background to what exporting such data would enable those acting in bad faith to the letter of the license, whats happened here is that 1) emacs users didn't get better highlighting 2) kdevelop never had a chance to even consider gcc as a result and 3) gcc is now failing to compete with another compiler that it really needs to.
What's better, a dead but libre compiler that doesn't interop, or one that has a degree of compromise while still having an effective license that risks proprietary vendors "freeloading" on some good work?
While I don't write and don't like C++, I don't understand why major foss projects choosing clang over gcc due to a philosophical spat is anything other than damning.
gcc should be fighting hard to continue to provide features competitive to clang while remaining true to it's values, but instead it has opted out of this for hypothetical purity (exporting the data in question is within the license terms and does not require changes in gcc itself, it can be implemented as a plugin, rms just doesn't like it and discourages loudly its implementation as it simply makes it easier for proprietary tools to use it. The situation is quite similar to dynamic linking).
> While I fully understand the technical background to what exporting such data would enable those acting in bad faith to the letter of the license, whats happened here is that 1) emacs users didn't get better highlighting 2) kdevelop never had a chance to even consider gcc as a result and 3) gcc is now failing to compete with another compiler that it really needs to.
Yes, that is not the most beautiful moment in the libre software movement. I'm pretty sad about it.
> 3) gcc is now failing to compete with another compiler that it really needs to.
I'm not sure this is true, is gcc really competing with clang? I personally don't perceive there to be competition.
I'm not clear on the emacs situation though, is emacs unable to call out to clang for metadata because of the license?
Regardless, correctly parsing c++ is just about the toughest problem there is when it comes to parsing programming languages. Besides clang, gcc, and the parsers in open source projects like qt creator, kdevelop (these two used to be related iirc, but now both are clang i believe), and eclipse cdt, there aren't any free ones. All the rest are closed source. Last I heard microsoft licensed the c/c++ parser they use from a third party. There's value in being able to parse c++ correctly, clang is really exceptional in addressing tool support in this way.
Offtopic: I really loved their variable coloring when I used to work with it. Basically there's a hashing function that maps the variable name to a certain set of colors. It helps to quickly notice what variable is used where.
Is there such plugin for ST2, perhaps for VSC?
Note: You'll find yourself renaming variables just to get a different color :)
> Basically there's a hashing function that maps the variable name to a certain set of colors. It helps to quickly notice what variable is used where.
Thats sounds like my nightmare! ;)
I'm very easily distracted by too much coloring, so this just doesn't work
for me. If I want to see the usage of one variable I just highlight the
usage of this one variable.
I've been a regular user of KDevelop for quite a while now. It's simply the best tool for reading existing code, with the variable coloring and powerful code navigation.
It doesn't have that many features that would be useful for writing code (refactoring other than renaming, auto private pointers, maybe helpers for Qt properties), but I'm glad they moved to Clang as the C++ parser. Can't way till it gets to Arch repos.
I can only show KDE to my friends and boast off saying that Linux is the best, in order to make them install a Linux distribution, I show several compiz features and Kate, to show highlighting in different colors, then blaming them for using such lame OS(windows), without any highlighting features for notepad, and Alt+ tab graphics being so lame for windows, customizable, I use Manjaro to get some best applications pre-installed.
"Apart from those changes, KDevelop 5 has of course be ported to KDE Frameworks 5 and Qt 5. This will for the first time enable us to offer an experimental version of KDevelop for Microsoft Windows in the near future, in addition to support for Linux."
They already did, except that other project managers are supported as well (in kdev4, these are CMake, custom makefile, and generic). Apparently they are adding qmake. The KDevelop "project" file (something.kdev4) only has two lines -- the project name and the choser project manager.
28 comments
[ 3.3 ms ] story [ 99.4 ms ] threadGet kdevplatform from: git://anongit.kde.org/kdevplatform
Install kdevplatform, kdevelop, kdev-rust, etc. into the same install prefix (-DCMAKE_INSTALL_PREFIX=/foo) and you should be fine.
Also have a look at: https://community.kde.org/KDevelop/HowToCompile_v5#3._Run_KD... for setting up the env before running KDevelop.
This exact topic notoriously came up last year where emacs wanted to use exported gcc datastructures to highlight code. This proposal was disallowed by rms sticking so dogmatically to his core values that one GNU project ended up not being able to interact with another, for fear of proprietary vendors doing so.
While I fully understand the technical background to what exporting such data would enable those acting in bad faith to the letter of the license, whats happened here is that 1) emacs users didn't get better highlighting 2) kdevelop never had a chance to even consider gcc as a result and 3) gcc is now failing to compete with another compiler that it really needs to.
What's better, a dead but libre compiler that doesn't interop, or one that has a degree of compromise while still having an effective license that risks proprietary vendors "freeloading" on some good work?
gcc should be fighting hard to continue to provide features competitive to clang while remaining true to it's values, but instead it has opted out of this for hypothetical purity (exporting the data in question is within the license terms and does not require changes in gcc itself, it can be implemented as a plugin, rms just doesn't like it and discourages loudly its implementation as it simply makes it easier for proprietary tools to use it. The situation is quite similar to dynamic linking).
Yes, that is not the most beautiful moment in the libre software movement. I'm pretty sad about it.
I'm not sure this is true, is gcc really competing with clang? I personally don't perceive there to be competition.
I'm not clear on the emacs situation though, is emacs unable to call out to clang for metadata because of the license?
Regardless, correctly parsing c++ is just about the toughest problem there is when it comes to parsing programming languages. Besides clang, gcc, and the parsers in open source projects like qt creator, kdevelop (these two used to be related iirc, but now both are clang i believe), and eclipse cdt, there aren't any free ones. All the rest are closed source. Last I heard microsoft licensed the c/c++ parser they use from a third party. There's value in being able to parse c++ correctly, clang is really exceptional in addressing tool support in this way.
Is there such plugin for ST2, perhaps for VSC?
Note: You'll find yourself renaming variables just to get a different color :)
Thats sounds like my nightmare! ;)
I'm very easily distracted by too much coloring, so this just doesn't work for me. If I want to see the usage of one variable I just highlight the usage of this one variable.
I didn't wanted to imply, that I'm thinking this can't be configured in KDevelop.
[1]: https://github.com/ankurdave/color-identifiers-mode
I've been a regular user of KDevelop for quite a while now. It's simply the best tool for reading existing code, with the variable coloring and powerful code navigation.
It doesn't have that many features that would be useful for writing code (refactoring other than renaming, auto private pointers, maybe helpers for Qt properties), but I'm glad they moved to Clang as the C++ parser. Can't way till it gets to Arch repos.
Well, see you later!