| Re: [cdt-dev] Possible Bug in org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription |
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
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.To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
From: Andrew Gvozdev
Sent by: cdt-dev-bounces@xxxxxxxxxxx
Date: 06/24/2013 11:57AM
Subject: Re: [cdt-dev] Possible Bug in org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescription
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,
I think this was already reported:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=408525
If you push a patch to gerrit it's more likely to get looked at and accepted.
http://wiki.eclipse.org/Getting_started_with_CDT_development
http://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT
Marc-Andre
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Joseph Henry [Joseph.Henry@xxxxxxx]
Sent: Monday, 24 June 2013 11:29 AM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Possible Bug in org.eclipse.cdt.managedbuilder.internal.buildmodel.BuildDescriptionHi,
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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-devDISCLAIMER: 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.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
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.