Bugzilla – Full Text Bug Listing
| Summary: | ${project_loc} not defined for project external builders | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeff McAffer <jeffmcaffer> |
| Component: | Ant | Assignee: | Platform-Ant-Inbox <platform-ant-inbox> |
| Status: | CLOSED INVALID | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | darin.eclipse |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
"project_loc" is not what you want - it resolves to the selected project or to the named project when a argument is present (like "${project_loc:Foo}").
I think you want "build_project": Returns the absolute file system path of the project currently being built, or the absolute file system path of the resource identified by an optional argument interpreted as a path relative to the project currently being built.
Thanks. That works.
Have to say though that from a user point of view its a bit odd. ${project_loc} works fine in a target definition.
Closing
|
in 3.7m2a create a project hat has some and build.xml file in it and the try to configure it as a external builder in the project properties. If you set the script location to something like ${project_loc}/build.xml you get an error saying essentially that ${project_loc} is not defined. Interestingly this seems to only happen in some situations. I can't quite pin down when but I think the build is sometimes working. If you instead use ${workspace_log} that always works but forces you to encode the name of the project in the location. Since this is not hooked into refactoring, the builders break every time you rename the project.