Bugzilla – Full Text Bug Listing
| Summary: | LLVM toolchain support | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Petri Tuononen <petri.tuononen> | ||||||||||
| Component: | cdt-core | Assignee: | Doug Schaefer <cdtdoug> | ||||||||||
| Status: | RESOLVED FIXED | QA Contact: | Doug Schaefer <cdtdoug> | ||||||||||
| Severity: | enhancement | ||||||||||||
| Priority: | P3 | CC: | aegges, alex.blewitt, caniszczyk, eclipse.sprigogin, eostroukhov, jamesblackburn+eclipse, leo.hippelainen, mail, malaperle, olexiyb, yevshif | ||||||||||
| Version: | 8.0 | ||||||||||||
| Target Milestone: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| URL: | https://code.google.com/p/llvm4eclipsecdt/ | ||||||||||||
| Whiteboard: | |||||||||||||
| Attachments: |
|
||||||||||||
|
Description
Petri Tuononen
Created attachment 190046 [details]
LLVM plug-in
Created attachment 190047 [details]
LLVM plug-in sources
Created attachment 190049 [details]
Feature project
Created attachment 190050 [details]
Adds LLVM plug-in to cdt.releng
Not sure if done correctly.
As discussed here: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg21163.html And also found an early thread: http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg13034.html The plug-in is fully EPL and thus complies fully to CDT coding standards. The plug-in doesn't include LLVM binaries. Assigning to core for greater visibility... Hi Petri. I'd like to help out. I'll report issues I find and attach patches at Google Code. The mailing list doesn't seem to work though, I think it's announce only. Given that the IP review deadline has passed, we could work on polishing it for next year's release. Hey Marc! Great that you can help me out. Especially those issues with priority high or critical should definitely be fixed. I had to change mailing list settings so now posting to the mailing list is allowed to all members. I also figured out that it can't make it to CDT 8.0 and it's better that it works well before releasing to large audience. Also Marc I can add you as a committer on Google code, but for that I need to know your gmail address. You can contact me via petri(dot)tuononen(at)gmail(dot)com. Sounds like a good plan to do a bit more work on it at Google Code then resubmit. It's unfortunate that we missed the Indigo deadlines only by a few weeks, but I'd be happy to start including it in CDT HEAD (hopefully 'master' by then ;) once we have CDT 8 out the door at the end of June. Documentation available at http://petrituononen.com/sites/default/files/Thesis%20-%20Petri%20Tuononen.pdf Is there any further plans to make this available, now that Indigo is out of the door? Sure. Personally I would like to see it stable as soon as possible (the beta is available through the Eclipse marketplace). I am just too busy at the moment with other work. I have to admit that currently there are more issues than I would like to admit. I assume it takes couple of months to fix it. I have yet to see what autumn brings and try to work then. I would not mind if someone wants to help though. It is difficult to see when it will be finished as I am the only one developing it in a zigzag manner. Hi, I haven't looked much into the logic of the code yet but one thing I would like to bring up it how the code is commented:
//remove white spaces
dir = dir.trim();
if (dir.length()!=0) {
//get all existing items in the list
String[] existingItems = getList().getItems();
...
It seems a lot of the comments are very obvious and could be taken out. I'm not saying they should be all removed though.
I don't know much about build so take that as you will but it seems backwards to me that the LLVM preferences goes through all projects and configurations and adds the paths. What if the project is shared and LLVM doesn't have the same paths? It seems to me scanner discovery should use the LLVM preferences as a first indicator of where it should find the paths.
(In reply to comment #14) > Hi, I haven't looked much into the logic of the code yet but one thing I would > like to bring up it how the code is commented: > > //remove white spaces > dir = dir.trim(); > if (dir.length()!=0) { > //get all existing items in the list > String[] existingItems = getList().getItems(); > ... > > It seems a lot of the comments are very obvious and could be taken out. I'm not > saying they should be all removed though. That's true that most of the comments are quite obvious at least when considering that CDT code generally doesn't have any comments except Javadoc. I just wanted to make sure that there are enough comments to understand the logic quickly rather than one comment less. > > I don't know much about build so take that as you will but it seems backwards > to me that the LLVM preferences goes through all projects and configurations > and adds the paths. What if the project is shared and LLVM doesn't have the > same paths? It seems to me scanner discovery should use the LLVM preferences as > a first indicator of where it should find the paths. Good suggestions are always welcome. Sure this needs to be changed. I just currently don't know much about scanner discovery. LLVM is on my mind. I want to make sure it works on ok on Windows before we throw our support for it. I'm also concerned about LLVM's support for C++11. It seems way behind gcc according to the llvm website. So need to get a real understanding of the status there too. (In reply to comment #16) > I'm also concerned about LLVM's support for C++11. It seems way behind gcc > according to the llvm website. So need to get a real understanding of the > status there too. I know people who are working on C++11 support in LLVM. It is at least on par with gcc 4.5 and will get the rest of features soon. (In reply to comment #17) > (In reply to comment #16) > > I'm also concerned about LLVM's support for C++11. It seems way behind gcc > > according to the llvm website. So need to get a real understanding of the > > status there too. > > I know people who are working on C++11 support in LLVM. It is at least on par > with gcc 4.5 and will get the rest of features soon. Very cool. Thanks Sergey. I figure they were further ahead than I thought. There is a lot of momentum behind LLVM which is why we should be taking a good look at adding support for it to our exemplary offerings. Sorry about how long it's taken for me to get around to this. But I finally have the need for this toolchain support. I'm working on Qt support for CDT and am working on my Mac where Qt uses clang by default. Petri, are you still interested in contributing this. Is this the latest bits? Thanks! (In reply to comment #19) > Sorry about how long it's taken for me to get around to this. But I finally > have the need for this toolchain support. I'm working on Qt support for CDT > and am working on my Mac where Qt uses clang by default. > > Petri, are you still interested in contributing this. Is this the latest > bits? > > Thanks! Sure I am interested, but the problem is that I do not have much time as I am now a full-time student and also full-time software developer. Unfortunately these will not leave time. The latest revision can be found from the project website: https://code.google.com/p/llvm4eclipsecdt/ I have to admit that it is now a bit outdated, because LLVM is now on version 3.2 and also few bugs should be fixed. Cool. I don't think it'll need much time from you. I just need get the paper work done so I can get legal approval to get it checked into CDT. I'm happy to continue working on it as needed now that I have a Mac. And of course, as you have time, you can keep the contributions coming :). I'll start things up and let you know what I need next. Thanks! (In reply to comment #21) > I'll start things up and let you know what I need next. Could we make it it's own branch so we can fix some issues before it gets into master? Last time I tried it, I noticed a few things that need to be fixed, like the second part of Comment 14. This bug should probably be fixed first: https://code.google.com/p/llvm4eclipsecdt/issues/detail?id=53 We can make it an optional feature so it won't be included in CDT packages until it's ready. This is how we've handled other integrations like this. As I recall, there were also some API changes for which we did not reach a consensus. I agree with Marc-Andre that it would be better to put it on a branch. I just checked them out into my environment as is and things are working satisfactorily without any API changes. And besides, API changes aren't allowed to begin with so there shouldn't be any impact on the rest of the CDT. I don't want to create a branch since i need it to work on my Qt stuff and that's in master. Sorry, I confused it with pkg-config bug 44761. I am supportive about adding LLVM toolchain. (In reply to comment #27) > Sorry, I confused it with pkg-config bug 44761. I am supportive about adding > LLVM toolchain. Thanks Andrew. Yes, pkg-config is a whole other story, and yeah, needs some re-architecting to fit in properly. I notice someone is contributing patches there so maybe things are getting better. But first things first. I've created the IPzilla request to bring this over. The deadline for Kepler is about now. I definitely want to get this in for the upcoming release. For committers who have access to the IPzilla system, the CQ number is 7075. Petri, can you confirm you've written 100% of the code and that you the rights to contribute this. Thanks! Ah, looking at the legal notices, I see that Leo Hippelainen also contributed to this. We'll need this question answered by everyone who's contributed. Thanks! I will notify Leo and ask him to confirm. (In reply to comment #31) > I will notify Leo and ask him to confirm. On behalf of myself and Nokia Siemens Networks (my employer) I give necessary permissions to share the program code written by me under terms of EPL. I am glad to see that great effort Petri has put on this becomes acknowledged. I wish I had had more time to contribute myself. Perhaps some day... BR, Leo H. PS. If my wording here does not serve the legal requirements, let me know. (In reply to comment #32) > (In reply to comment #31) > > I will notify Leo and ask him to confirm. > > On behalf of myself and Nokia Siemens Networks (my employer) I give > necessary permissions to share the program code written by me under terms of > EPL. > > I am glad to see that great effort Petri has put on this becomes > acknowledged. I wish I had had more time to contribute myself. Perhaps some > day... > > BR, Leo H. > PS. If my wording here does not serve the legal requirements, let me know. Thanks Leo! Petri, can you provide the same confirmation? I also give necessary permissions to share the program code written by me under terms of EPL. The plugin does not work with the latest version of LLVM 3.2, because llvm-ld (linker) tool has been removed from this version. I try to find a solution when I have time. Thanks Petri! I'll get the wheels going again for this. Once it's in I can give the linker issue a lot as well. The Contribution has been approved by Eclipse legal. I'll start work on bringing the plug-ins over. I've added the plug-ins to the llvm folder in master. I'll work at adding them to the builds, including a feature to make this an optional component. Thanks Petri and Leo for this great contribution. *** cdt git genie on behalf of Doug Schaefer ***
Bug 338553 - import plugins from llvm4eclipse. Just importing everything
they had in svn.
[*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=b4ccbb274848e4edf2da9e1409f7166ec071d988
|