| Re: [cdt-dev] Possible Bug in org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription |
Sorry Andrew! My fault! I should have provided more info but it was quite late when I wrote the email and I longed for my bed! First note that the workspace plugin code does include the 3 patches I submitted for bug 408525, bug 411726 and bug 411728. Thus you won’t reproduce any of those bugs with this workspace but will always have success. To reproduce the bug you will have to go back to the original code for BuildDescription.java and BuildDescriptionManager.java. Team sharing the plugin org.eclipse.cdt.managedbuilder.core of the imported eclipse workspace should enable you to do that easily. 1- Once you have restored the original file (Keep the new one) start an instance of the eclipse application for a debugging session. 2- I forgot to delete the test C++ project from the test debugging session project. Please delete the project content on disk. 3- Create a new C++ Hello world project (May be using a new name) 4- Open the setting properties dialog of the project 5- In the tool pane choose the category Developer Testing. You then have 2 testing options. 6- By default the Test Output Bypass is set to disable (This is the default CDT Output Type behavior) 7- Don’t compile the new project until later otherwise you wont be able to reproduce the issue (Indeed the working directory will be created) 8- Set the option to Enable Output Default bypass : This will force use of the NameProvider associated class. 9- From now on The Bypass output file (path/name) enumerated option should be enable. 10- Chose the enumerated option : Absolute Path Outside of Workspace. 11- Try to do a first compile 12- You will have a fail. Note that the fail of step 12 is likely to be a consequence of bug 408525. Apply the 408525 patch. I expect another fail again caused by bug 411726. Apply the patch for 411726. I expect another fail again caused by bug 411728. It was late when I wrote the code. Thus I might have forgetting something. If you have any issue reproducing the bug let me know! I’ll do a few more test on my own to make sure I haven’t forgotten something and keep you posted on the CDT-Dev list. Thanks for your help Guy From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Andrew Gvozdev Hi Guy, I downloaded your file and opened the workspace but I am still at loss what I am supposed to do to reproduce any of your issues. In particular I had bug 411728 in mind. Thanks, Andrew On Thu, Jun 27, 2013 at 12:59 AM, <Guy.Bonneau@xxxxxxxxxxx> wrote: I have uploaded to skydrive a zipped workspace project that demonstrates the bug 408525 but also a proposed solution to bug 408525, bug 411726 and bug 411728. Here is the link to the shared skydrive: I have modified the visual studio plugin.xml to add a new category option in the Compiler tool called Developer testing. This category contains 2 options. The first option : “Test Output Bypass” is an enumerated option that enable/disable the capability to specify a different output location than the default CDT Builder usage. When enabled a second enumerated option called “Bypass output file (path/name)” specifies the location of the output file from the compilation output. 6 different file locations can be used to test the behavior of the CDT builder. With the standard unpatched CDT code I believe only 1 out of 6 paths will work. With the current patched code the 6 paths yield the expected output file creation at the expected location. To use the zipped workspace with the current enumerated file locations you need to extract the project to the root of your C drive (Under Windows of course) and keep the same paths specified in the zipped file. Note that I haven’t a deep knowledge of the CDT architecture yet. Thus the proposed patch is only a template. Also note that I haven’t tried under Linux. If you have any questions let me know. Thanks! Guy
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Date: 06/24/2013 01:36PM
Hi Guy, In cases like that you would attach a sample plugin exhibiting this behavior. Thanks, Andrew On Mon, Jun 24, 2013 at 1:25 PM, <Guy.Bonneau@xxxxxxxxxxx> wrote: You're right! I fall through this issue why developing a proprietary toolchain. In fact you are not likely to get it since you need to override the default use case behavior of the toolchain implementation. I had this issue when I defined a nameProvider class to override the default CDT implementation of the OutputType in a tool definition. In my case the nameProvider class was returning a full path with name and extension of the output tool in which case the issue kick-in. If I don't use a nameProvider the CDT default behavior doesn't fall through the issue. Guy To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx> Still, the bug does not tell how tell how we can reproduce. Thanks, Andrew On Mon, Jun 24, 2013 at 11:50 AM, Marc-André Laperle <marc-andre.laperle@xxxxxxxxxxxx> wrote: Hi Joseph, From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Joseph Henry [Joseph.Henry@xxxxxxx] Hi, I am on a team at my company to integrate our development build process into the Eclipse CDT. I think I might have ran across a bug in the CDT code. I am using the latest Juno version of the plugin. In the class org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription beginning at line 1005: if(projLocation.isPrefixOf(outProjPath)) { // absolute location really points to same place the project lives, so it IS a project file outProjPath = outProjPath.removeFirstSegments(projLocation.segmentCount()); outFullPath = projLocation.append(outProjPath.removeFirstSegments(projLocation.segmentCount())); outWorkspacePath = fProject.getFullPath().append(outProjPath); } This is the area of code that is causing me problems. It seems like the first line after the if should not be there, or if it is, then the “outProjPath.removeFirstSegments(projLocation.segmentCount())” should not be in the second line. This causes the first two path segments after the project location to be lost, which causes a resource conflict in a certain situation. Here is an example that will cause the resource conflict. INPUT FILE -------------- OUTPUT FILE C:\Project\subdir1\src\file1.c ------------------- C:\Project\subdir1\out\dir2\file1.obj C:\Project\subdir2\src\file1.c ------------------- C:\Project\subdir2\out\dir2\file1.obj As you can see, these files have the same name, and produce output of the same name, but the path is unique, so a resource conflict should not exist, But given the above code, the variable outFullPath will be transformed to C:\Project\dir2\file1.obj instead of C:\Project\subdir2\out\dir2\file1.obj which is what I am expecting. How can I go about getting this patched in my release? Thanks, Joseph Henry.
_______________________________________________ DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
_______________________________________________ DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
|