Using pack files for HAL?

[cw2]

I am considering to use parts of the official STM HAL driver library for Cortex-M7 port and because there has been already an ongoing discussion about including third party source code in NETMF codebase and possible usage of .pack files #434 (comment), I am looking for the right directions and feedback.

In my particular case, I could find only one .pack file for Cortex-M7 that contains needed HAL driver source code, namely Keil.STM32F7xx_DFP.2.7.0.pack available as a free download from Keil's MDK5 Software Packs page.

The problem is this file download is several hundred megabytes and expands into more than one gigabyte (!) of contents, most of which is irrelevant for my case (not saying completely useless, but the HAL driver is a few .h and .c files, negligible part of the whole package).

The alternative is to use STM32CubeF7 that also contains the HAL driver, and has similar additional contents, which is not needed...

Thus, personally I would rather include [only actually used parts of] the STM HAL driver library in the NETMF codebase (in a similar way how it has been already done by @josesimoes in his PR).

The long-term solution could be use of packages specifically designed for NETMF (then the question would be why not use an existing mechanism such as nuget, with a NETMF feed).

Thoughts?

[cw2]

Note: I am not sure there are any guarantees from ARM and/or Keil regarding the availability of old versions of their software pack files, which poses a risk (I guess no need to mention the famous NPM tale from March 2016). Additionally, there have been already changes in the .pack format and schema, that caused Pack Installer application to stop working and required upgrade to newer version (of the whole Keil MDK).

[josesimoes]

@cw2 I'm all for pack files. Not sure what is the license or the accepted use of the Keil packages if you don't own a license... With the ST packages that doesn't happen because you can use it as long as you are building code for an aplicable part (which is obviously the case).

As for the changes in format and schema, I guess there is no much one can do except adapt and make the required changes if/when required.

Regarding packages availability (current and future) I don't see anyone making any claims on the matter... so one might as well start collecting the relevant packages... 😉

[smaillet-ms]

The pack files are the preferred way and the current thinkin g is to integrate support for pack files directly into the tooling for the next major release. (Including sharing the local pack rep with MDK) While we won't be dependent upon pack files we do need to deal with the fact that they are a growing presence and supporting them directly relieves developers of a ton of manual porting.

In other words we need to deal with packages of various types (CMS, Nuget, yotta, etc...) via an abstraction that allows for multiple sources of code to be unpacked and or referenced by NETMF build projects without needing to manually copy/tweak them. (Some tweaking is inevitable but it should be reduced to the same requirements if you were building "Hello World" in uVision or other environments the packs were defined for.

[cw2]

@smaillet-ms Thanks for the explanation, this is solution I am happy about.