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

> - I do not quite understand what Jan means. I do think that rethinking and documenting some parts of the design would be nice though.

I believe Jan is a more in depth design question that exceeds the basic managed model design. I will reply to his email separately soon.

> - I do not think that *removing* a separate Clang (LLVM???) plug-in is the way to go. [...]

I agree. We should have separate Clang plug-in with its own wizard entries and settings pages.

As a clang/llvm user, can we call it the clang (what case) plug-in. The existing GCC feature is called "C/C++ GNU Toolchain Build Support" with the wizard/template entries being variants of Linux GCC, Cygwin GCC. etc. Would "C/C++ clang Toolchain Build Support" with the wizard/template entries being variants of Linux clang, Cygwin clang. etc. be a correct mapping? 

> - I prefer to leave out the non-Clang(++) stuff 

Are you recommending having no LLVM stuff other than clang support in CDT? If so, I agree.

 > FWIW: I really *hate* and don't (maybe want to) understand all the [...]

Fair enough - the plugin.xml for extension points in general is a very good system. The toolchain definitions with their options, while powerful, is verbose and fiddly.

> [...] readable tutorial for creating Eclipse plug-ins that explains the whole extension point stuff?

Have a look at https://www.vogella.com/tutorials/EclipsePlugin/article.html.

Thanks,
Jonah

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


On Sat, 18 Jan 2020 at 12:14, Joost Kraaijeveld <J.Kraaijeveld@xxxxxxxxxx> wrote:
Hi,

At the moment I have:

- created a local bug535565 branch from CDT-9_10_0,
- removed the LLVM-page from Eclipse by removing the LLVM-preference
page in the org.eclipse.cdt.managedbuilder.llvm.ui plugin.xml,
- commented out the code that caused the bugs 535565, 527757 and
probably 500186.

As far as I have tested, it now works for me (Linux, Debian Testing,
i.e. Debian/Bullseye, Clang only). I have attached a patch created by
choosing "Team->Synchronize workspace", select all differences, "create
patch", and then saved it as file.

Some questions...

- Is this enough for getting a minimal real working Clang-support for
the next release of the CDT? If so, what should be my next steps?
If nt: what do you expect?
- Should I remove all the code that is related to the removed LLVM-
preference page?
- What do you hope that I should do more as a minimal effort form
improvement?
- What should be my next steps?

For the future:

- I do not quite understand what Jan means. I do think that rethinking
and documenting some parts of the design would be nice though.
- I do not think that *removing* a separate Clang (LLVM???) plug-in is
the way to go. Although Clang is very compatible with GCC, it also has
specific differences.  Copy&paste re-use and manually maintaining
(structural) similarity comes to mind. E.g. GCC and Clang share a lot

of stuff but seem to be surprising unrelated in terms of the CDT-plugin
- I prefer to leave out the non-Clang(++) stuff because I do not know
anything about the LLVM-stuff. I think that the CDT should compile
C/C++ programs.

FWIW: I really *hate* and don't (maybe want to) understand all the
configuration/declarative XML-stuff. I prefer readable real code. Does
anyone knows a readable tutorial for creating Eclipse plug-ins that
explains the whole extension point stuff?

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

Back to the top