Ship examples and documentation in separate repositories to reduce checkout size

[rgilton]

A checkout of this git repository takes up about 1.4 GB on disk, and cloning it pulls about 150 MB across the net. Most of this disk and bandwidth is comprised of the example projects, as well as some particularly large documentation files. There are also some files that seem somewhat unecessary like this 2 MB bitmap image, and this 26 MB of audio files that will be very infrequently used.

We would like to use this repository as a git submodule within our firmware projects, but this causes problems:

• Every firmware project we have would take up 1.4 GB on disk, so we'd waste quite a lot of disk space.
• Our CI pipeline builds will be slowed down by using it. On a fast connection (Linode box) it currently takes about 12 seconds to pull this repository across the net, and then another 10 seconds to actually unpack it onto disk. Adding 22s to every CI build slows us down.

Our workaround at the moment is to make a repository of our own with the same structure as this one, with all the extra stuff removed. This brings the repository size down significantly (to about 11 MB, which takes less than a second to pull across the network), but comes at the expense of making it harder to upgrade to a later version of STM32CubeF4, as we have to go through that process every time.

Please will you consider splitting this repository up into several repositories -- I imagine at least this set:

• The minimal source for building against (presumably most things in Drivers -- the things in Middlewares would presumably be better suited in a separate repository anyway, as they are presumably replicated in other STM32CubeF* instances too...)
• An examples repository
• Potentially a documentation repository

[andyn-ff]

I would enthusiastically support this change!

[josesimoes]

I'm with the www.github.com/nanoFramework project and we have this same problem. Like @rgilton we have a clone of this repo with a branch for CD-CI on which we strip the docs/samples/etc to have only the source files.

I'm aware that the repos with HAL drivers only are available, but on some series, we require other drivers too. So this is an issue for us too.

I second this!

[ALABSTM]

Hi @rgilton,

Thank you for tackling this aspect. Actually, the STM32CubeF4 and equivalent ones constitute a first step forward to offer a better alternative to the ZIP packages already provided on the st.com website.

The second step is effectively to provide each component in a separate repository.

• As @josesimoes pointed out, we have already published the CMSIS and the HAL components in separate repositories.
• The publication of the MW and the BSP components will follow. We cannot share a date for the moment. But we are actively working on the subject.

The list of all there repositories is maintained here.

We hope to provide solutions as satisfactory as possible to our customers and users. Feedback and remarks as yours are more than welcome as they help us identify areas of enhancement. Thank you once more.

With regards,

[rgilton]

Ok, good to know that there is a plan to separate these things apart. Does this mean that bugs and pull-requests for the CMSIS and HAL components should be registered against those repositories?

Would you accept a pull-request that made the CMSIS and HAL components in this repository use the separate CMSIS and HAL repositories as submodules? Then there would be less ambiguity.

[ALABSTM]

Hi @rgilton,

We are also working on that aspect. We are studying the possibility to use the submodules, among other possibilities, in order to make it easier to manage all these repositories.

Your contribution is more than welcome! It would allow us to have an extra proposal to base our analysis on.

With regards,

[ALABSTM]

Hi @rgilton,

Any update? For you information, it seems git subrepo is far more efficient than git submodule.

With regards,

[ALABSTM]

Hi @rgilton,

We recently published the following firmware libraries:

• stm32_mw_fatfs
• stm32_mw_freertos
• stm32_mw_lwip
• stm32_mw_usb_device
• stm32_mw_usb_host

Next step will be the publication of the BSP and the Projects. We hope this will help you and all the users avoid the inconvenience of downloading large-size full packages.

Please allow me to close this issue now. Thank you again for having tackled this subject.

With regards,