Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] LLVM/Clang toolchain broken
Thank you for that background information. Your explanation also explains why I had to install llvm package on Ubuntu even though I already had a working clang++. The current code looks for llvm-ar to decide if the LLVM toolchains are available rather than clang or clang++. I can also see things like the linker command in the build definition is llvm-ld which I expect is now out of date.

I would vote to remove the existing LLVM plug-in and for creating a new clang one that does it properly. It may be we can just reuse all the build definitions or extend the existing gcc ones? As for process it may be that simply rebranding the plug-in&feature to clang/clang++ is best. I leave whoever takes up this challenge to decide which is best.

Finally I would like to thank Petri for the original LLVM contribution. While it is now under review, it added value to CDT when it was first added. 

Thank you,
Jonah



~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 17 Jan 2020 at 22:51, Marc-Andre Laperle <malaperle@xxxxxxxxx> wrote:
Hi,

From what I remember, the intention of the preference page was to be able to add the system headers which a prebuilt clang did not know about at all and you had to specify manually. This preference page would be global to all projects and configurations. But this is not the way normally managed build projects are configured. In fact, it did this global setting by adding the include paths to every projects and every configuration, before every build and regardless of the toolchain! Also, post-build it would always do a full workspace refresh which I had to comment out because people were complaining quickly that Eclipse was unusable while this plugin was installed.

In the midst of the enthusiasm of having LLVM support, I don’t think this plugin was fully tested or thoroughly reviewed because there were/are glaring issues. I personally ended up using the GCC toolchain and just replacing the command with clang and clang++ which worked fine (especially once many OS/distros had a prebuilt clang fully configured with system paths, etc) so the motivation of fixing the LLVM toolchain was/is low. Still, I think it would be a nice project to go back and clean up the LLVM plugin (…or remove it). A first obvious clean-up would be to remove the preference page and any concept of global include path and libs. Another step would be to remove the many tools and toolchain that I don’t believe people use or are still maintained (LLVM-GCC, LLVM + JIT, etc). Then there is general code clean-up (there shouldn’t be obvious comment for every line).

Cheers,
Marc-André

On Jan 17, 2020, at 12:20 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:

Hi Joost,

Thank you for your analysis up until this point.

In my new role as CDT project lead there are a number of areas that I am simply not familiar with (yet!) and this is one of them. 

I can try to provide some background, and I will be very happy to review any patches you provide!

To answer some of your questions:

The LLVM plug-ins were added in Bug 338553 and haven't changed much since then in the particular area of the code you have highlighted. 

From a quick look at this it seems there is a confusion in this code between settings passed to the LLVM compiler and those passed to the CDT indexer and which tool is "in charge". In simple cases that difference probably doesn't matter, but it clearly quickly goes wrong (the case in Bug 527757 is particularly obviously bad).


> - Is there any (high level) design documentation available for the LLVM managedbuilder stuff? Or for GCC?

Have a look at https://wiki.eclipse.org/CDT/designs/MBS it contains design documentation for when managed build was first added and has a number of links that may be useful. 

> - Why is there a CDT LLVM preference page? What is/was it's purpose?

I don't know. There may be answers in the Petri's thesis, but the link to it is dead (see comment).

> There is no such page for GCC?

Because it probably shouldn't exist for LLVM either?

> - I cannot find UI for LLVM/Clang project properties. Can someone
enlighten me?
> - The same for the GCC project properties?

It is in the Project Properties -> C/C++ Build -> Settings. (see attached file to confirm we are talking about the same thing)

Thank you for taking the time to look at this. There is certainly a lot of little bits needed to get a C++ Managed Build project to "just work" and I look forward to supporting you where I can.

Thanks
Jonah




~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Fri, 17 Jan 2020 at 09:11, Joost Kraaijeveld <J.Kraaijeveld@xxxxxxxxxx> wrote:
Hi,

My immediate personal problem is solved by placing a comment on line 62
of LlvmResourceListener.java to prevent
LlvmPreferenceStore.addStdLibUnix() being called.


I suspect that the same should be done on line 59 but I have no Windows
with MinGW to test it with.

--
Groeten,

Joost Kraaijeveld
Hommelseweg 123
6821 LD Arnhem
06-51855277

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev
<Screenshot_2020-01-17_12-16-40.png>_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top