C/C++ developers are used to work with standard IDE such as Microsoft Visual Studio and CodeWarrior, two products that have been designed from the start to be C/C++ IDEs.
One area that is specific with developing in C/C++ is the source file layout. C/C++ source files are divided in headers and sources files, are often shared between projects, and have no rigid layout in the file system.
Some teams group the C/C++ files by software component, some by framework, some by teams, and some by a bit of every division imaginable. C/C++ source trees end up being very complex, and it is of course out of the question to ask developers to structure their sources according to the way an IDE works, the IDE has to adapt itself to the way developers work!
Eclipse's solution for creating arbitrarily complex project structure is using linked resources.
Unfortunately, Eclipse's linked resources have the following limitations:
- Linked resources tend to contain absolute paths, unless the workspace's path variables are used.
- When path variables are used to avoid using absolute paths, the variable list is maintained in the workspace only, and if the user switches workspace, the project becomes broken.
- The linked resource's targets can't be changed by the user in the workbench!
- Linked resources can't be specified as being in a parent directory relative to a path variable (i.e. "PROJECT_LOCATION/../../dir/foo.c").
- Creating linked resources is very time-consuming, the user has to create each single file one by one through the new file wizards.
What we have done for our customers at Freescale is improve Eclipse's support for linked resources while maintaining full compatibility with standard Eclipse IDEs.
We can divide our improvements in 4 different sections:
Project Path Variable Manager
The first improvement consists of creating a IPathVariableManager implementation in each project, analogous to the one at the workspace level.
Then, the path variable list is extensible through an extension point, which allows default variable to be specified (such as PROJECT_LOCATION, ECLIPSE_HOME, etc...) and custom variable to be provided by 3rd party plugins.
For instance, a StarCore tool plugin may want to expose its SDK root as a path variable, so that each project can contain sources from the SDK, while having the source locations always pointing to the correct location.
A dialog has been added to handle drag and drop of files in the project, so the user can easily and quickly create a path variable relative project structure.
Special path variables are provided, such as "PARENT" which allows path variables to be specified as relative to the parent directory of another variable, effectively allowing arbitrarily complex project structure to be specified while keeping the project fully portable across computers, or "ENV" which allows linked resources to be relative to environment variables.
Since each project has its own PathVariableManager, special care had to be taken to be sure that copying linked resources that contain path variables between different projects causes the proper path variables to be copied as well.
Also, the user can now change the linked resource target in the file property page.
Groups
C/C++ developers are used to group source and header files differently than they are structured on the file system. In Visual Studio, the user can create filters in a solution, while with CodeWarrior, groups can be created. In Eclipse, the user has currently no choice but to create a set of empty directories, which is then cumbersome to maintain in a source repository and awkward to use.
For that purpose, we have added support for groups in Eclipse that the user can easily create anywhere in a project. A group works just like a folder, and is fully compatible with the existing core.resources API and all its clients, the only difference between a group and a folder is that:
- Groups are not created on the file system, they are instead recorded in the .project file.
- Only linked resources and groups can be created under a group, no real files or folder can, since a group is only a virtual container.
Internally, groups are implemented as folder linked resources.
Additional features
We have also provided a dialog that allows the user to list all the linked resources in a project and easily manage them.
The user can automatically convert absolute path linked resources to path variable relative, and fix broken linked resources.
We hope that our improvements can be useful to other Eclipse users, and welcome your comments, questions and criticisms!
Our changes are freely available in the following Eclipse bug report, and we hope to be able to contribute the changes back to the Eclipse standard distribution:
No comments:
Post a Comment