Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-core-dev] Re: Flexible Project Structure

Hi Glenn! :)

Thanks for your comments, I think your requirement list overlap a great deal the requirement we had as well, namely:

(A) is covered by the proposed design (and implementation) that we provided in the freescale patch plugins. The core.resources plugin how has an additional extension point that other plugins can implement and define additional variables that can be used to resolve linked resources. The variables "PROJECT_LOC", "WORKSPACE_LOC" and "ENV" are provided by default, but additional products benefit from having source tree variables being provided, such as "STARCORE_SUPPORT", etc...

(B) and (C) are also fully supported by our design.

(D) How we handled the issue with broken links and absolute paths is by providing a small tool that the user can invoke by right-clicking on the project resource. The tool then lists the linked resources and group them by "relative path", "broken links", and "absolute paths links". The powerpoint presentation attached to this email describe a little bit this tool. Although we haven't provided the source of that tool in the freescale patch plugins we submitted to the eclipse bug database, we can certainly make it available on demand.

We haven't addressed (E) with our proposed design, although it sounds interesting. From our perspective what is missing is that, although that it is currently possible to add a project dependency ("Project references") to an existing project, it isn't possible to specify a dependency for a specify CDT build configuration. So for instance, the debug build configuration of one project can't rely specifically on the build configuration of another project, only on the currently active build configuration of its dependency.

Serge Beauchamp.
Software Engineer
Freescale Semiconductor

Glenn Meter wrote:
Doug,

I'm coming in late to this discussion. But as an Eclipse Java user and as a former lead of the CodeWarrior IDE team, here's my two cents.

My suggested basic requirements are:

(A) Allow linked resources to resolve to absolute paths or paths relative to one of:
    - The project
    - A workspace variable
    - The workspace

(B) Projects that only use paths relative to the project should be able to be checked out from CM into a new [CM] workspace and "just work" (whether on my machine, another machine with the same OS, or another machine with a different OS). I should not have to create any symbolic links or do any other setup to be able to edit, compile, and debug the application.

(C) The resolution for a linked resource should be able to be viewed and changed via the Properties for the item. In 3.3, if a linked resource uses a workspace-variable-relative path and the variable is not defined then the Properties page for the resource does not show the resolution information. This makes it difficult to fix the problem by declaring the missing workspace path variable. It's not possible to fix the problem without viewing the .project file.

(D) Any referenced but undefined workspace path variables should show up in the workspace's Problems list.

(E) Projects should be able to refer to other projects, and include a preference for whether the referenced projects should be built before the referring project. If I have a project hierarchy, I should not have to duplicate the hierarchy in each workspace that includes a root project.


I also agree with Serge (hey, Serge!) that it should be easier to create linked resources in general via drag & drop, etc.


I'm looking forward to see what you come up with at the E4 Summit.

Best regards,
Glenn Meter
meter@xxxxxxxxxxxxxx
gmeter@xxxxxxxxxxxx


_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-core-dev

Attachment: ProjectFileStructure.ppt
Description: Binary data


Back to the top