Re: Using IC manufacturer header files


Carles Cufi
 

Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Wednesday, April 20, 2016 19:24
To: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>
Cc: Nashif, Anas <anas.nashif(a)intel.com>; devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 10:50 PM, Cufi, Carles
<Carles.Cufi(a)nordicsemi.no> wrote:
Hi Maciek,

-----Original Message-----
From: Maciek Borzecki [mailto:maciek.borzecki(a)gmail.com]
Sent: Tuesday, April 19, 2016 17:27
To: Nashif, Anas <anas.nashif(a)intel.com>
Cc: Cufi, Carles <Carles.Cufi(a)nordicsemi.no>;
devel(a)lists.zephyrproject.org
Subject: Re: [devel] Re: Using IC manufacturer header files

On Tue, Apr 19, 2016 at 5:04 PM, Nashif, Anas <anas.nashif(a)intel.com>
wrote:
Hi,
Any files or headers included from an external project that need to
be
kept in sync with upstream can keep their style and formatting to
allow updates in the future. This was the approach taken when we
imported the IP stack from contiki AFAIK.

How about keeping the library/headers external and passing their
location in Kconfig? Similar to what buildroot does with external
kernel/toolchains. Is that acceptable too?

Not sure if you mean pulling the source code from another repository
at build time, since I don't know what buildroot does with
kernel/toolchains.
However the MDK is not currently available in a repository, instead it
is released as a .zip file by Nordic every time it gets updated. We
could of course mirror it in a repo, but that would anyway require us to
update it manually every time a new version is available.

What I meant is that you keep the {S,M}DK externally and just configure
a path to it inside Kconfig. You can add a config entry like
CONFIG_STM32F1_STDLIB_PATH. Then in project/driver makefiles
-I$(CONFIG_STM32F1_STDLIB_PATH) and optionally add some files to the
build as needed. This has one major advantage, that the 3rd party code
is kept outside of Zephyr repository, so you basically don't care about
the naming/conventions/licenses 3rd party libraries would use.
I couldn't find the CONFIG_STM32F1_STDLIB_PATH you mentioned, and I tried to build the "hello_world" sample for STM32 and it worked fine, even though I have no STM SDK installed at all. With that I mean that it looks like, so far, archs are self-contained. The problem with the "-I$(NORDIC_MDK_PATH)" approach is that, as you mention later, Nordic might change the folder structure of the .zip file that it provides, rename some files and change it completely, leaving us at the mercy of the vendor.

As for mirroring 3rd party SDK in a repo. No matter the vendor's
distribution method I always pull the source code into a git repository
for two main reasons:
By pulling into the repo I assume you mean actually duplicating the files inside the target repo, instead of "pulling" them from an external repo.

- I don't trust vendors to have a reasonable release management (more
often than not they prove to have none)
Agreed, see point above. Sometimes there's legitimate reasons to change the structure of the SDK provided by a vendor, but the OS build shouldn't be affected by it. Furthermore, relying on a particular version could potentially then introduce dependency hell into the Zephyr build for certain architectures, where some users would start to complain that the OS doesn't build for a particular IC because they have an older (or newer) IC vendor SDK than the one that Zephyr depends on.

- you cannot rely on developers putting/extracting SDK's at proper
locations and setting their dev environment
Yes, this is especially troublesome in this case. The MDK is delivered as a .zip file for Linux and there is no installer or standardized path for it.


The multi repository projects can be easily remedied by using `repo`
tool or git submodules.
Although that is true, it would break the current seemingly desirable feature of the Zephyr codebase, and that is it being self-contained. Git submodules or repo add an additional layer of complexity to users, and that is not something I envision introducing at this point.

So far we have a nice, self-contained repo with a subset of (almost) untouched Nordic MDK files in the arch folder. We'll start with that and see how that works in the future.

Thanks,

Carles

Join devel@lists.zephyrproject.org to automatically receive all group messages.