SPARC BSPs Fail to Build rtems-libbsd

[Chris Johns]

On 27/05/2015 11:30 am, Joel Sherrill wrote:
> 
> 
> On May 26, 2015 8:21:10 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>> On 27/05/2015 11:00 am, Joel Sherrill wrote:
>>>
>>>
>>> On May 26, 2015 7:51:18 PM CDT, Chris Johns <chrisj at rtems.org> wrote:
>>>> On 27/05/2015 8:14 am, Joel Sherrill wrote:
>>>>>
>>>>> It looks the PCI API change has resulted in rtems-libbsd not
>>>>> building for SPARC. Any ideas?
>>>>
>>>> The code unconditionally assumed all BSPs provided PCI support and
>>>> installed "rtems/pci.h" header. I have just posted a patch that adds
>>>> conditional support the waf build of rtems-libbsd so the LEON3 BSP
>> now
>>>> builds.
>>>
>>> Is this really a mistake on the libpci side? Shouldn't it install the
>> header as rtems/pci.h?
>>>
>>
>> If there is no PCI bus why should the header be installed ? It is a
>> simple why for users and external packages to know if PCI is supported.
>> If you add the header do you need to add the calls as well ?
> 
> Not arguing that. Just saying the other targets install the shared PCI header file as rtems/pci.h. if it is an enhanced compatible api, then it should be in the same place. 
>

Are you referring to the leon3 drvmgr/pci_bus.h, pci.h etc headers that
are installed for this BSP ? I am not familiar with it's specifics.

> The support libraries can compile but if there is no PCI on the board, then the PCI drivers will never get linked. So dead code in the library but that's no big deal. Cpukit just needs to be consistent and this has one architecture install a .h file in a unique place. It is wrong.

If the LEON3 has a special PCI interface then I have no problem with
libbsd not building PCI support for it. If the LEON3 is updated to
support the standard interface libbsd will build the support.

It is not clear to me if you see a problem with the change I posted.

Chris