Discussion:
[meta-freescale] Fixing imx-vpu-hantro header installation
Carlos Rafael Giani
2018-07-27 14:01:02 UTC
Permalink
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.

--
Tom Hochstein
2018-07-31 15:33:34 UTC
Permalink
Thanks, Carlos, we will fix these issues.

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

Tom
-----Original Message-----
Sent: Friday, July 27, 2018 9:01 AM
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
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
--
Carlos Rafael Giani
2018-07-31 16:13:11 UTC
Permalink
I was actually working on a patch myself. I could send that in during
the next few days.

Carlos
Post by Tom Hochstein
Thanks, Carlos, we will fix these issues.
Does this require an immediate fix, or can it wait until our next upstreaming?
Tom
-----Original Message-----
Sent: Friday, July 27, 2018 9:01 AM
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
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
--
Tom Hochstein
2018-07-31 16:14:40 UTC
Permalink
That's great, thanks again.

Tom
-----Original Message-----
Sent: Tuesday, July 31, 2018 11:13 AM
Subject: Re: [meta-freescale] Fixing imx-vpu-hantro header installation
I was actually working on a patch myself. I could send that in during the next few
days.
Carlos
Post by Tom Hochstein
Thanks, Carlos, we will fix these issues.
Does this require an immediate fix, or can it wait until our next upstreaming?
Tom
-----Original Message-----
Sent: Friday, July 27, 2018 9:01 AM
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.
Post by Tom Hochstein
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.
Post by Tom Hochstein
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
https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fli
sts.yo
ctoproject.org%2Flistinfo%2Fmeta-
freescale&data=02%7C01%7Ctom.hochstein%40nxp.com%7C3725db8cffb
94138838308d5f3cb1624%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0
%7C636682975941245444&sdata=K3DIn5sHeK5INkwp3YxABiBvoGUkiWYy
Post by Tom Hochstein
nUa0po5ASsw%3D&reserved=0
--

Loading...