Bug 408525 - Build resource properties are wrongly computed by class BuildDescription when Path of resource is absolute.
Summary: Build resource properties are wrongly computed by class BuildDescription when...
Status: NEW
Alias: None
Product: CDT
Classification: Tools
Component: cdt-build-managed (show other bugs)
Version: 8.1.2   Edit
Hardware: All All
: P3 blocker (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Jonah Graham CLA
URL:
Whiteboard:
Keywords:
Depends on: 411726 411728
Blocks:
  Show dependency tree
 
Reported: 2013-05-20 21:08 EDT by guy bonneau CLA
Modified: 2020-09-04 15:23 EDT (History)
3 users (show)

See Also:


Attachments
Proposed patch (3.54 KB, patch)
2013-06-27 00:22 EDT, guy bonneau CLA
no flags Details | Diff
Full file (69.26 KB, application/octet-stream)
2013-06-27 00:22 EDT, guy bonneau CLA
no flags Details
Proposed Fix (1.20 KB, patch)
2013-06-27 09:22 EDT, Joseph Henry CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description guy bonneau CLA 2013-05-20 21:08:24 EDT
Method addOutput of class BuildDefinition compute the wrong properties of output resource path when the path provided as argument is absolute. 

At line 1002 when the condition if(outFullPath.isAbsolute()) is true and path is inside Eclipse's workspace  then 3 paths of the output resource are computed: the full Path of the resource, relative project Path of the resource and relative workspace of the resource. These paths are embedded in the returned resource object.

The current computing is: 

  outProjPath = outProjPath.removeFirstSegments(projLocation.segmentCount());
  outFullPath = projLocation.append(outProjPath.removeFirstSegments(projLocation.segmentCount()));
  outWorkspacePath = fProject.getFullPath().append(outProjPath);

Note that straight after the condition if(outFullPath.isAbsolute())is true the code assigns outProjPath = outFullPath;

The current first line compute the good outProjPath value. However the first reassign outProjPath with a new value being the resource path relative to the project path. Because of this reassignment the outFullPath cannot be resolved to it true definition.

The outFullPath must be computed before outProjPath. Thus the first 2 lines must be reversed.
Comment 1 guy bonneau CLA 2013-06-24 12:23:36 EDT
Typo:

The class is BuildDescription
Comment 2 guy bonneau CLA 2013-06-27 00:22:16 EDT
Created attachment 232817 [details]
Proposed patch
Comment 3 guy bonneau CLA 2013-06-27 00:22:54 EDT
Created attachment 232818 [details]
Full file
Comment 4 Joseph Henry CLA 2013-06-27 09:22:46 EDT
Created attachment 232841 [details]
Proposed Fix
Comment 5 Joseph Henry CLA 2013-06-27 09:22:55 EDT
I have also ran into this bug, but I find the proposes solution to be much too complicated.

I have also attached a proposed solution patch, that is simply a 1 line change.
Comment 6 guy bonneau CLA 2013-06-27 09:46:53 EDT
Joseph,

I already proposed the same fix than yours on the cdt-dev email list. A 1 line fix. Unfortunately the issue is much more complex because other issues exist in the same method that you'll probably never tested. There is at least 2 others issue in the same method bringing the number of issues to 3 within this method.

The second issue is when the output location is both relative and the relative path segment is greater than 1 relative to the project path: See the line code :

   if (outFullPath.segmentCount() == 1) {

You will also ran into a fail.

The third issue is when the output location is outside of the workspace path. This case is dismissed by the method because it is wrongly assumed it is not possible to build a path relative to the workspace location. Yet it is possible and I demonstrated this (See the CDT-Dev email list). 

After much pondering I concluded it was much better to rewrite the whole routine (which I did) to solve the 3 issues rather than the first one only. This make the CDT builder much more flexible regarding the output location.

Note that the whole rewriting of the method is already much simpler than the original code.