Community
Participate
Working Groups
When adding a converter for a Tool using the new MBS converter extension point, the converter is never called. The problem is in the routine ManagedBuildManager.checkForMigrationSupport. The converter code stores information in the project objects while loading the project. The code in checkForMigrationSupport is looking for this information in the wrong place. It is looking in the manifest file configurations, rather than the project file configurations. I'd like to fix this for CDT 3.0. A proposed patch will be added soon. The patch is small and low-risk, and the functionality just doesn't work without it.
I agree, we should fix this for 3.0. We really need this.
Created attachment 25065 [details] Proposed patch Chris & Mikhail, Please review the patch. Thanks, Leo
I tried after applying this patch with a toolchain. It works better, but I'm still having a problem that I think is related to CDT 2.0->3.0 conversion. Basically a custom converter isn't set if the project is originally read in using the old target/toolref model and then converted to the new model in memory. Therfore the converter is never called. If I then exit Eclipse and start it again, then converter will be called. I think it would probably work OK for 2.1->3.0, but I don't have a CDT 2.1 installation, so I can't confirm.
Leo, Your patch looks good to me. Jeremiah, Leo might want to correct me, but it looks that the converte mechanism is not intended to be used for cdt versions<=2.1 Thanks, Mikhail
I think probably CDT 2.0 is a low priority, although of course not for us ;). CDT 2.0 is however, mentioned in the specification at least once, which gives the impression that it will work. Also, it is incredibly close to working so I don't see a reason not to support it if someone wants it. I do understand if it is too low priority/risky to make CDT 3.0, though.
Hi Jeremiah, I would certainly like this functionality to also work with CDT 2.0 projects. If you have a chance to determine what is wrong, attach a patch to this bugzilla and we'll consider it. I have a couple of people here starting to look at it as well. Would it help you if this got fixed in a CDT 3.01 release (a couple of months out), or is that too late? Regards, Leo
I have a number of things, including this, that we would like to possibly put in a CDT 3.0.1. However, from a planning perspective I'm not sure when it would be available. We're looking to put out a CDT 3.0 product soon, and we ship "stock" CDT, so we at TimeSys will have to come up with alternate solutions unless CDT 3.0.1 falls within our timeframe. If it's a couple of months that may be OK. If it's mid to late Q4, that may be too late. Regardless of whether we will be using it, I am willing to help with this. I'll see if I can figure out a simple amendment for the patch.
Created attachment 25157 [details] Update patch for CDT 2.0 conversion This patch is a super set of the previous. I solved this by making checkForMigrationSupport() public in Tool, ToolChain, and Builder, and explicitly calling it while running the CDT 2.0 converter. There might be a more elegant solution, but this does work. I sucessfully saw my "dummy" converter called for each of the three supported element types.
Hi Jeremiah, you mentioned in the comment that "Basically a custom converter isn't set if the project is originally read in using the old target/toolref model and then converted to the new model in memory. Therfore the converter is never called". when will this case arises? I am trying to understand. Is it possible to provide a test case for this or can you explain me in more detail ? I am thinking that there may be some problem with test case itself. I would like to see the test case. Thanks & Regards, Sunil (In reply to comment #3) > I tried after applying this patch with a toolchain. It works better, but I'm > still having a problem that I think is related to CDT 2.0->3.0 conversion. > Basically a custom converter isn't set if the project is originally read in > using the old target/toolref model and then converted to the new model in > memory. Therfore the converter is never called. If I then exit Eclipse and > start it again, then converter will be called. I think it would probably work > OK for 2.1->3.0, but I don't have a CDT 2.1 installation, so I can't confirm.
Created attachment 25191 [details] Test plugin for use in CDT 2.0
Created attachment 25192 [details] Test Plugin for use in CDT 3.0
OK. I can't send you our actual toolchain, but I attached an example which can reproduce the same problem. Use CDT 2.0, with attached plugin. Create a Managed C Project with the test project type. Close Eclipse. Use CDT 3.0 (with other attached plugin), open the same workspace. It will prompt you to update the project (open C/C++ build properties if it doesn't prompt immediately). Click yes. Upgrade will be "sucessful" and build info will be visible, however the converter class will never be called. Close Eclipse. Open it again (using CDT 3.0). Converter class will be called after restart (again open C/C++ build properties if not called immediately). I was using both plugins in a self-hosted environment, with the appropriate Eclipse. Eclipse 3.0.1, CDT 2.0.2 for "old". Eclipse 3.1, CDT head + leo's patch for "new".
I have applied my initial proposed patch. Other fixes will likely have to wait until post-3.0.
Hi Jeremiah, Thanks for attaching the test case. I am able to reproduce the problem and also I identified another issue. There are two problems. i) If the converters are written based on CDT 2.0 model, they are never called due to the condition added on 06/28/05 in the loadBuildInfo() function code to fix some other problem. This takes a more time to fix the problem. ii) A custom converter isn't set if the project is originally read in using the old target/toolref model and then converted to the new model in memory and the converter is never called. For 2nd problem, I have got a solution and works with the test case. I need to review the patch again before sending it to Leo or other committers. Thanks & Regards, Sunil (In reply to comment #12) > OK. I can't send you our actual toolchain, but I attached an example which can > reproduce the same problem. Use CDT 2.0, with attached plugin. Create a > Managed C Project with the test project type. Close Eclipse. Use CDT 3.0 > (with other attached plugin), open the same workspace. It will prompt you to > update the project (open C/C++ build properties if it doesn't prompt > immediately). Click yes. Upgrade will be "sucessful" and build info will be > visible, however the converter class will never be called. Close Eclipse. > Open it again (using CDT 3.0). Converter class will be called after restart > (again open C/C++ build properties if not called immediately). > I was using both plugins in a self-hosted environment, with the appropriate > Eclipse. Eclipse 3.0.1, CDT 2.0.2 for "old". Eclipse 3.1, CDT head + leo's > patch for "new".
Hi Jeremiah, Your proposed patch has been applied to the 3.0 branch and mainstream. Thanks, Leo
