search

Open-CMSIS-Pack / devtools

Open-CMSIS-Pack development tools - C++
Apache License 2.0
74 stars 56 forks source link

Proposal for shorter file/pathnames #314

Closed ReinhardKeil closed 1 year ago

ReinhardKeil commented 2 years ago

Using the test project AWS_MQTT_MutualAuth_Demo from https://github.com/RobertRostohar/ctools_lab, currently the following files /directories are created in .\example\IoT\AWS_MQTT_MutualAuth_Demo:

AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7_IntDir
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7_OutDir
AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7_IntDir
AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7_OutDir
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS3_Corstone-300_IntDir
 :
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS3_Corstone-300.cprj

While this makes it easy to identify the relationship between *.cprj and IntDir/OutDir it creates long pathnames quickly.

This is a suggestion to shorter path names while at the same time reducing directories and the length of the directory names. The output files of one project always use the same directory. The benefit is that post-steps like programming can always use the same output filename as there is no difference between Debug and Release build in the path/file name. Combining a Release build of a Boot part with a Debug build of an Application part is therefore easier.

tmp\AVH_MPS2_Cortex-M7\Debug
out\AVH_MPS2_Cortex-M7
tmp\AVH_MPS2_Cortex-M7\Release
out\AVH_MPS2_Cortex-M7
tmp\AVH_MPS3_Corstone-300\Debug
 :
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Release+AVH_MPS2_Cortex-M7.cprj
AWS_MQTT_MutualAuth_Demo.Debug+AVH_MPS3_Corstone-300.cprj

In CMakeLists.txt there is a set (TARGET ... command that also contributes to long path names. Suggestion is to just use the project-name, in this example: set (TARGET AWS_MQTT_MutualAuth_Demo) as the directories provide already enough separation.

We might need to introduce configuration options in csolution to configure directory names, but before further exploration feedback on this proposal would be good.

VGRSTM commented 2 years ago

Is not https://github.com/Open-CMSIS-Pack/devtools/pull/266 contributing to ?

ReinhardKeil commented 2 years ago

I suggest to implement the following to control the build environment under solution: and project:.

build-control:                    # section that configures the build process
  outdir:  path-name              # explicit pathname for output files, default is 'out'
  intdir: path-name               # explicit pathname for interim files, default is 'tmp'
  rtedir: path-name               # explicit pathname for configuration files, default is 'RTE'
  build-type-out: separate        # separate build-type output in the same way as interim files (default: combine)

The rtedir will require additional features in the cbuild step, but is included to conver #266

VGRSTM commented 2 years ago

To be fair not sure to understand fully your proposal if The output files of one project always use the same directory. Are we not going to face conflicts ? What about end user is aiming to build:

brondani commented 2 years ago

The PR #388 was implemented based on proposals #221 and #314. The yml schema extensions from PR #266 are accepted but initially only at csolution level and therefore must be relative to the csolution.yml file. The proposed variables are implemented as access sequences and follow the format:

$Project$
$BuildType$
$TargetType$
$Compiler$

The default values for the directories:

output-dirs:
    cprjdir: {cproject.yml's directory}
    rtedir:  {cproject.yml's directory}/RTE
    intdir:  {csolution.yml's directory}/tmp/$Project$/$TargetType$/$BuildType$
    outdir:  {csolution.yml's directory}/out/$Project$/$TargetType$/$BuildType$

Setting a custom RTE directory requires additional changes in cbuild that will be provided in PR https://github.com/Open-CMSIS-Pack/devtools/pull/391. Also the suggestion of changing the CMake target name needs to be planned considering the multi-project scenario during the CMakeLists generation, so it is not changed in this PR. Reminder: CMake target names in a CMake project must be unique.

ReinhardKeil commented 1 year ago

@brondani this is mostly complete, but the default behavior for the tmp directory, might need review. Is the part Demo.Debug+WiFi.dir really required given that we have already tmp\Demo\WiFi\Debug in the path? Not sure if this is a problem of cbuild rather then csolution

C:\w\AWS_MQTT_MutualAuth_SWFramework\tmp\Demo\WiFi\Debug\CMakeFiles**Demo.Debug+WiFi.dir**\C\w\AWS_MQTT_MutualAuth_SW_Framework\Board\B-U585I-IOT02A\STM32CubeMX

brondani commented 1 year ago

@ReinhardKeil The directory Demo.Debug+WiFi.dir in your example is created by cmake and it's derived from the CMake target name. In the current scenario where each project context is built separately it could be made shorter, but in a multi-project scenario each CMake target must have an unique name.

ReinhardKeil commented 1 year ago

@brondani thanks for the answer. Is there a way to change the behavior of cmake. Can we influence this part of the path name?

The part tmp/Demo/WiFi/Debug makes the tmp directory already robust enough for multiple context settings.

I believe the multi-project scenario you indicate would require that multiple *.csolution.yml include the same *.cproject.yml in the same directory.

brondani commented 1 year ago

@ReinhardKeil AFAIK we can change this directory name only by changing the CMake target name. In the multi-project scenario that I mentioned all project contexts are part of the same CMake Project, in other words they have a single "solution" CMakeLists.txt entry point, regardless of yml files location, so CMake can handle interdependencies, build order, etc. In this case the CMakeFiles directory doesn't need to be in the last subfolder but it could be right under tmp/. We must investigate further and define how the multi-projects build will look like.

ReinhardKeil commented 1 year ago

A lot has been done on this issue, but still some optimizations could be done. I have summarized it here #558