[RTEMS Project] #2434: general gpio.h is no longer installed leading to build breakage

[RTEMS trac]

#2434: general gpio.h is no longer installed leading to build breakage
---------------------+--------------------------------
 Reporter:  beng     |       Owner:  Ben Gras <beng@…>
     Type:  defect   |      Status:  reopened
 Priority:  normal   |   Milestone:  4.12
Component:  General  |     Version:  4.12
 Severity:  normal   |  Resolution:
 Keywords:           |
---------------------+--------------------------------

Comment (by chrisj):

 Replying to [comment:4 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 [comment:5 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? ;)

--
Ticket URL: <http://devel.rtems.org/ticket/2434#comment:6>
RTEMS Project <http://www.rtems.org/>
RTEMS Project