Naming of files and folders makes for more work when porting?

[doingnz]

Is there a technical reason for the files and folders under the following folders to be prefixed with the 'CPU' name?

.\netmf\netmf-interpreter\DeviceCode\Targets\Native\STM32 .\netmf\netmf-interpreter\DeviceCode\Targets\Native\STM32F4

Given the high level STM32 and STM32F4 folders partition the sub-folders, the common items below them could have the same names.

e,g,: .\Native\STM32F4\DeviceCode\STM32F4_Bootstrap\STM32F4_bootstrap.cpp

might be called: .\Native\STM32F4\DeviceCode\Bootstrap\bootstrap.cpp

under STM32 it would also be .\Native\STM32\DeviceCode\Bootstrap\bootstrap.cpp

Which would make it easier to port an existing solution to support another platform avoiding all the search/replace/rename. It would be much easier to compare files from different Native Platforms at the folder level. e.g. to compare .\Native\STM32F4\DeviceCode\*.* .\Native\STM32\DeviceCode\*.*

The current schema means a lot of work to just rename files and folder paths in projects for an unclear benefit.

Thoughts?

[smaillet-ms]

No technical reason. Just apparently following the pattern of a separate folder for each SOC family that was established in the beginning. Reality is that most such families go a long way to share common silicon components (This hasn't always been true in the past). I'd be perfectly happy to see consolidation and removal of redundant code for the next release.

[cw2]

Related to #29 (use mbed libraries ?)

[doingnz]

The barrier to HW vendors needs to be as low as possible.

I am suggesting removing the SOC name from the files and sub folders of a parent SOC folder.

It is then easier to use your favorite Diff tool to compare all the files and folders in two different SOC.

Porting to a new SOC starts with a copy of the closest existing SOC implementation to its own SOC folder. Currently also need to rename all the subfolders and all the files and fix all the project paths to use the new SOC copy. Might need something similar to $(SPOCLIENT) that points the the parent SOC folder, then can avoid search and replace in SOC project files.

For me to use MF 4.4, I need to add back support for generic ARM9 as I am still using the Meridian HW module from Device Solutions. (iMXS Arm920t).

I wanted to do a quick diff of my existing iMXS DeviceCode files to the new STM32xx versions. But not so easy to do given the mismatch in folder and file names.

[smaillet-ms]

It's important to keep in mind that descriptive file names are a critical part of how things actually work in the NETMF build. Since the NETMF code base is designed for portability and, in fact builds with multiple toolchains the impact of changes across tools needs to be considered. In particular many embedded linkers don't accept multiple object modules with the same name. That is, file foo.o from one part of the source tree cannot be linked into the same image as foo.o from some other part of the image. This is the primary reason why the files have such descriptive/qualified names. The folder hierarchy doesn't really matter, but the unique names for the object files do. Since the object file names are derived from the source file name, the source file name becomes important. It's plausible that the build project system could be adjusted to provide a prefix for the object file (we already have a property for the path) but that's a lot of work to change and test everything in the tree.