[meta-freescale] Fixing imx-vpu-hantro header installation

Tom Hochstein tom.hochstein at nxp.com
Tue Jul 31 08:33:34 PDT 2018


Thanks, Carlos, we will fix these issues.

Does this require an immediate fix, or can it wait until our next upstreaming?

Tom

> -----Original Message-----
> From: meta-freescale-bounces at yoctoproject.org [mailto:meta-freescale-
> bounces at yoctoproject.org] On Behalf Of Carlos Rafael Giani
> Sent: Friday, July 27, 2018 9:01 AM
> To: meta-freescale at yoctoproject.org
> Subject: [meta-freescale] Fixing imx-vpu-hantro header installation
> 
> Currently, the headers from imx-vpu-hantro are installed in the ${includedir}
> directory, which is /usr/include/ in Yocto.
> 
> This is bad, because there are multiple headers, and none of them have names
> that are distinguishable enough. There are headers called codec.h, version.h,
> util.h for example.
> 
> Placing multiple headers into /usr/include/ that belong to a specific library or
> package is not good. In the Unix world, it is generally considered good practice
> to place such headers in a subdirectory instead.
> 
> I would recommend doing that here as well. Let the imx-vpu-hantro recipe
> create a "hantro/" or "imx-vpu-hantro/" subdirectory in ${includedir}, and install
> the headers there. I realize that the imx-vpuwrap and imx-gst1.0-plugin recipes
> expect the headers to be in ${includedir}, but this can be circumvented by adding
> an include path command line flag to their CFLAGS. I think this is preferable over
> keeping these headers in the main include directory.
> 
> Also, the preprocessor definitions that the top level makefile selects are not
> specified in any header. Typically, such options are recorded in something like
> config.h so that code that uses the library can use #ifdef to make sure its code
> matches. For example, there is the USE_EXTERNAL_BUFFER macro, which is
> enabled in the toplevel makefile.
> This macro enables additional fields in several C structs, so knowing whether or
> not imx-vpu-hantro was build with this macro is important.
> 
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yo
> ctoproject.org%2Flistinfo%2Fmeta-
> freescale&data=02%7C01%7Ctom.hochstein%40nxp.com%7C3725db8cffb
> 94138838308d5f3cb1624%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
> %7C636682975941245444&sdata=K3DIn5sHeK5INkwp3YxABiBvoGUkiWYy
> nUa0po5ASsw%3D&reserved=0


More information about the meta-freescale mailing list