general gpio.h is no longer installed leading to build breakage

[Ben Gras]

The bsp-general <bsp/gpio.h> is no longer pre-installed, presumably since commit 5458bff92 regenerated preinstall.am. This causes build breakage for BSP's implementing the gpio interface (e.g. beagle):

arm-rtems4.11-gcc --pipe -B../../../../../.././lib/ -B../../../../../.././beagleboneblack/lib/ -specs bsp_specs -qrtems -DHAVE_CONFIG_H -I../../../../../../../../rtems-src/c/src/lib/libbsp/arm/beagle/../../../libcpu/arm/shared/include -mcpu=cortex-a8 -O2 -g -Wall -Wmissing-prototypes -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs -MT libbsp_a-gpio.o -MD -MP -MF .deps/libbsp_a-gpio.Tpo -c -o libbsp_a-gpio.o test -f '../../shared/gpio.c' || echo '../../../../../../../../rtems-src/c/src/lib/libbsp/arm/beagle/'../../shared/gpio.c
../../../../../../../../rtems-src/c/src/lib/libbsp/arm/beagle/../../shared/gpio.c:20:22: fatal error: bsp/gpio.h: No such file or directory

#include <bsp/gpio.h>

Thanks for Claudio Scordino and Debajyoti Majumdar for their interest in the Beagle BSP and for reporting this problem.

[Ben Gras]

Proposed patch

[Joel Sherrill]

Feel free to apply this to the master and 4.11 branch as appropriate.

[Ben Gras <beng@…>]

In [changeset:"6f6e5d758f6a1e7dcae74e151c3dd3d1034da232/rtems"]:

Error: Processor CommitTicketReference failed

/data/trac/repo/rtems.git does not appear to be a Git repository.

[Sebastian Huber]

On 06/11/15 23:57, André Marques wrote:

Hello,

This issue was resolved earlier with the following patch

​https://git.rtems.org/rtems/commit/c/src/lib/libbsp/Makefile.am?id=a57b72ded94b4e77fd4f9bd3cc37380a02e3e35a

where the inclusion of the GPIO API header file was removed from the libbsp/shared makefile and moved (in the case of the Raspberry Pi, but I forgot about the beagle BSP) to the BSP makefile which intends to use the API. This avoids these name clashes with BSPs that already have a gpio.h header file.

However the following patch reintroduced the gpio API header on the libbsp/shared makefile

​https://git.rtems.org/rtems/commit/c/src/lib/libbsp/Makefile.am?id=6f6e5d758f6a1e7dcae74e151c3dd3d1034da232

This last patch should be reverted, and the shared/include/gpio.h should be included in the beagle BSP makefile that requires it, and motivated this reintroduction.

I think it is better to have the BSPs include the gpio API header file if they actually implement the API, than forcing the header to all BSPs and creating these problems.

Às 14:29 de 05-11-2015, Sebastian Huber escreveu:

On 05/11/15 15:17, Martin Galvan wrote:

The LPC1768 variants have a gpio.h file whose name clashes with the gpio.h from
the new GPIO API. This results on the BSPs failing to compile.

This patch renames the LPC1768 gpio.* files to lpc-gpio.*, as it's done on other
BSPs (e.g. Beaglebone).

Closes #2441.

Thanks.

[Ben Gras]

All,

I see, sorry everyone, I wasn't aware of this problem.

Sebastian writes:

I think it is better to have the BSPs include the gpio API header file if they actually implement the API, than forcing the header to all BSPs and creating these problems.

As I see it, gpio.h is generic to BSPs (it describes a BSP-generic API) and so ought to be safe to install unconditionally.

Installing it only whenever BSPs implement the API isn't perfect either, as that precludes that BSP from having an installed gpio.h should they want it.

Can we install it unconditionally in a path that is safe from BSP-specific clashes?

[Ben Gras]

Or perhaps we can rename the generic gpio.h to a more specific name such as gpio-api.h.

[Chris Johns]

Replying to beng:

Sebastian writes:

I think it is better to have the BSPs include the gpio API header file if they actually implement the API, than forcing the header to all BSPs and creating these problems.

As I see it, gpio.h is generic to BSPs (it describes a BSP-generic API) and so ought to be safe to install unconditionally.

I agree with Ben and once we move to waf and have a single header tree with no pre-install stage this will be the case by default. We should have it in the tree now.

Installing it only whenever BSPs implement the API isn't perfect either, as that precludes that BSP from having an installed gpio.h should they want it.

Lets not do this.

Can we install it unconditionally in a path that is safe from BSP-specific clashes?

This will not happen in the single include tree.

The documentation for the BSP should clearly indicate the BSP supports GPIO. If I have selected a BSP without any GPIO pins and I need them I should consider a different career path. If the BSP has GPIO but no GPIO API support I should add the support.

Replying to beng:

Or perhaps we can rename the generic gpio.h to a more specific name such as gpio-api.h.

Please to not add 'api' to a header file name as a header by definition is an API. Should we add -c-language, -textfile etc as well? ;)

[Ben Gras]

I don't think we have agreed on a way out here, or did I miss something?

Or perhaps we can rename the generic gpio.h to a more specific name such as gpio-api.h.

Please to not add 'api' to a header file name as a header by definition is an API. Should we add -c-language, -textfile etc as well? ;)

Point taken, though I'm not sure I agree all .h files describe such a 'public' API. It seems to me something like what I suggested (rename gpio.h to something that a BSP would never name it) is a simple and reasonably clean (the BSP's won't have to be touched) way out. Is another name an option for you Chris? E.g. gpio-shared.h?