Alternative paths for user friendly project organization (add project_path attribute to component element)

[DavidJurajdaNXP]

Combination of base_path​, pack_path​, project_path​ could provide user friendly view in form of flat folder structure in workspace.
Flat folder structure - structure without unnecessary nested folders without files.

[ReinhardKeil]

David, thanks for the suggestion. Could you take the time to create an example (just text, not a real project), so that we better understand the request. It can be pretty simple.

Right now we show the Cclass as the identifier for a component group in the project window. I assume you would like to achieve something similar.

[tcsunhao]

@DavidJurajdaNXP , base_path is not the one work for shape project tree view. To provide user friendly view, "project_path" is enough.

[ReinhardKeil]

This seems to be related how IDE show software components (see here #93 (comment))

Is this correct? If not, what is the underlying problem you try to solve?

NOTE: we are working on a VS Code plug-in that provides a "Project View" for Open-CMSIS-Pack based projects.

[jkrech]

I believe the requirement here is about that the physical directory structure, allowing to control the destination of files belonging to a component when copied into the project folder (see #93).

[mark-edgeworth]

As I understand it, inside the implementation of a given component there may well be references between files that depend on the files remaining in their same relative locations when the pack is deployed. For example, #include "a/b/fred.h" requires that fred.c exists inside of a directory b which is itself inside of a directory a. Making this configurable after the component has been constructed sounds like a whole lot of complexity that would have to be supported by all tools.

In my view this is probably an issue only for the tooling, not for the specification. If the user wishes to reorganise files into some alternative structure the tooling should enable this by presenting the desired structure and maintaining a mapping to the original positions of the files. The underlying files should not move, and do not need to move. Only the presentation of the file structure may be permitted to change.

There is another aspect to this: the content of a pack should be immutable after it is constructed, otherwise any guarantees given about its quality or functionality are virtually impossible to maintain.

[tcsunhao]

I believe the requirement here is about that the physical directory structure, allowing to control the destination of files belonging to a component when copied into the project folder (see #93).

Yes, both #95 and #93 are actually consequence of NXP data model "project_path" attribute.

[DavidJurajdaNXP]

Let's limit scope of this ticket only to project_path.
project_path = data driven project explorer view

According to preliminary agreement in discussion #93 project_path will be introduced into standard, but actual usage will be tool specific.

Project_path must be applied on file paths and also on include paths in order to preserve data integrity.
In case of category="header" there should be way how to disable automatic include path generation.
<file category="header" name="ports/cmsis-driver/netif/ethernetif.h"/>

Project path is increasing complexity and in order to guarantee data integrity both layouts must be tested by pack vendor. It is price for this feature.

About the "Project View". I think it might be useful to have actually more views in IDE:

• component based view - showing content of components
• file based view - showing physical code organization in folders

I would call it views on different levels of abstraction. Another level might be "CMSIS layers".

[tcsunhao]

Agreed with @DavidJurajdaNXP , there can be 2 views in IDE workspace project tree

1. component layout.
   cclass, cgroup, csub can be used for this. With this information, developers can directly know the provenance and classification of the component(which pack it belongs to)
   
2. source tree layout
   project_path can be used to contruct it.
   It is an organization of the source under a component. Sometimes it could be untidy if sources are placed flat, like
   

[fred-r]

We support this request.
For most of the packs we need: #106

But we will deliver our example projects as packs.
And in these packs, we want the files to be copied in the user section of the project.
It is a bit like attr=template but we want it:

• for files that are not template but source and header
• mandatory (copy by the tool)
• flexible: indicate the path

[jkrech]

Change Request:
add component attribute "project_path". The implementation is optional and tools specific and will not change the virtual view.

@DavidJurajdaNXP and @tcsunhao can you please validate this summary.
It is my understanding that this attribute is somewhat comparable to #30 however affecting all configuration files of a component, rather than being specified on a per file basis and it only affects the path but not the filename.

[tcsunhao]

@jkrech , Thanks for approving this formally.

The project_path will affect all configuration files as well as other files when NXP tools use it to construct standalone project.

[tcsunhao]

Summary: The proposal is to add an optional component attribute named projectPath in the package description.
The projectPath has 2 functionalities which are all optionally decided by tools.

1. Used to construct project structure in IDE project explorer view.
   
2. For construction of standalone project, all files of the selected components are copied into the project directory for creating a self-contained project with no dependencies into the pack root directory. During this operation the projectPath attribute are not only used to construct the project explorer view but also determines the subdirectory where the files shall be stored.

[fred-r]

I understand that you want to fill 2 needs:

1. "simplify" the IDE view by applying project_path instead of the real file system path that can be longer
2. create a "standalone folder" with all the necessary files copied according to the project_path organization

But, the point which is unclear to me is: what about files going into RTE folder ?
Do you still put them in RTE folder ?

By the way, I assume this is an optional attribute.

[jkrech]

@fred-r, I think you are misunderstanding the feature suggested by @tcsunhao .
The projectPath attribute can be used by tools to copy both the config files as well as the component files of a component into a physical subdirectory of the project directory as specified by projectPath. The config files are copied along the component files and not into any directory.
The expectation is that a "virtual view" will continue display the files related to a component, and not the physical location of files on disk.

[tcsunhao]

Thanks for the explanation of @jkrech which is accurate and complete.
The projectpath is optional. Default value could be the real physical path of file.
Related files inside RTE folder, like startup_MK64F12.s(whose NXP project path is "startup"), in real folder, it is located in RTE\iar\Device\MK64FN1M0VLL12, in project explorer view, it can be showed listed inside "startup".