#2434 reopened defect

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

Reported by: Ben Gras Owned by: Ben Gras <beng@…>
Priority: normal Milestone: Indefinite
Component: unspecified Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

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.

Attachments (1)

fix-2434.txt (1.3 KB) - added by Ben Gras on Oct 21, 2015 at 2:58:23 PM.
Proposed patch

Download all attachments as: .zip

Change History (10)

Changed on Oct 21, 2015 at 2:58:23 PM by Ben Gras

Attachment: fix-2434.txt added

Proposed patch

comment:1 Changed on Oct 21, 2015 at 3:02:52 PM by Joel Sherrill

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

comment:2 Changed on Oct 21, 2015 at 3:07:17 PM by Ben Gras <beng@…>

Owner: set to Ben Gras <beng@…>
Resolution: fixed
Status: newclosed

In 6f6e5d758f6a1e7dcae74e151c3dd3d1034da232/rtems:

libbsp/Makefile.am: gpio.h as preinstalled header

Also regenerate preinstall.am. Closes #2434.

comment:3 Changed on Nov 10, 2015 at 9:17:33 AM by Sebastian Huber

Milestone: 4.11.14.12
Resolution: fixed
Status: closedreopened
Version: 4.104.12

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.

comment:4 Changed on Nov 11, 2015 at 2:51:44 PM by 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?

comment:5 Changed on Nov 11, 2015 at 2:55:37 PM by Ben Gras

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

comment:6 in reply to:  4 Changed on Nov 12, 2015 at 5:27:40 AM by 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? ;)

comment:7 Changed on Nov 18, 2015 at 4:01:58 PM by 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?

comment:8 Changed on May 11, 2017 at 7:31:02 AM by Sebastian Huber

Milestone: 4.124.12.0

comment:9 Changed on Aug 24, 2017 at 6:27:03 AM by Sebastian Huber

Milestone: 4.12.0Indefinite
Note: See TracTickets for help on using tickets.