On Fri, 2020-11-13 at 11:46 +0100, Norman Feske wrote:
Hi Piotr,
it is great to see the story behind your recent pull requests. Thanks for sharing it. I'm happy to read that the experience left such a good impression on you.
The code speaks for itself. When making the port I spent more time digging and learning about clang internals than actually fixing Genode to work with clang.
On 10.11.20 22:30, Piotr Tworek wrote:
The reaason I'm writing this email is to ask if Genode project would be potentially interested in having clang support in the main repo? I know that officialy supporting another compiler might not be an interesting prospect for the project and I won't mind if the answer is no.
We (as Genode Labs) are unable to officially offer support for a second compiler besides GCC because this addition would imply the need to double our CI efforts. But this economic constraint should not stand in the way of people who are fine with using another compiler at their own risk. As nicely illustrated by your pull request [1], the quality of our code base can only benefit from it.
I fully understand your position and I'm not aiming at replacing GCC with clang. Even if some of my more clang specific patches will ever be merged I fully expect this to be a community supported configuration rather than something officially endorsed and tested by Genode Labs. Obviously there needs to be a wider interest in clang support in Genode for this to make sense.
Besides the code-quality aspect, I find your direction interesting for two other reasons also.
First, I foresee an increasing relevance of tools like clang-tidy for our project. In the back of my head, I'm thinking of potential ways to formalize the use of Genode's coding style [2] beyond mere conventions. The clang project would be the most natural basis for creating a static analyzer with custom rules.
Second, when considering future support for languages like Rust or Zig, which rely on LLVM as their basis, we will need to attain a certain degree of compiler interoperability. Lowering the friction between Genode and Clang will ultimately help in this respect.
Well I won't hide that part of the reason I started this is I would like to at some point have zig support for Genode. I don't know if I'll ever make it this far, though.
[2] https://genodians.org/nfeske/2019-01-22-conscious-c++
Its enough for me if generic fixes I make get merged :). If there is an interest in clang support however, I'll be happy to spend a few evenings cleaning up my work and making a few more PRs out of it. If needed I can also push my remaing clang support patches in the existing, slightly chaotic form, to some branch so Genode developers can see how much work having clang support in Genode would entail.
Your generic fixes are more than welcome. :-)
Take cover, two more PRs incoming :P. https://github.com/genodelabs/genode/pull/3950 https://github.com/genodelabs/genode/pull/3951
I'm certainly supportive for giving Genode users the choice to use Clang as an option as long as it cannot be mistaken as a feature officially provided by Genode Labs. The documentation of this option could simply clarify that. So please don't hesitate to go forward. But don't feel pressured to hurry either.
Fully understand your position and I wouldn't have it any other way.
And since there has been some interest in my work I pushed what I have to: https://github.com/tworaz/llvm-project/commits/genode https://github.com/tworaz/genode/commits/clang
So far I don't have any prebuilt clang based toolchain available (at least not one that would work on most linux distros), so one has to build the LLVM based toolchain manually. Instructions on how to do this can be for example found here https://clang.llvm.org/get_started.html.
Once the LLVM toolchain has been built and insstalled it's enough to set GENODE_LLVM_TOOLCHAIN_DIR in tools.conf and specify USE_CLANG=yes when invoking make to build any of the Genode standard targets.
Cheers Norman