New Build System: Can't include headers

[Gedare Bloom]

On Mon, Jun 29, 2020 at 9:14 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:
>
> Hello,
>
> https://lists.rtems.org/pipermail/devel/2020-June/060145.html
> As agreed on the above mail I have started to create patches based
> on the new build system. But I encountered a few issues related to
> the inclusion of header files. I am using one of my patches as an example
> to illustrate the issues.
>
> The BUILD System was pulled from Sebastians build branch ( https://git.rtems.org/sebh/rtems.git/log/?h=build )
>
> PROJECT STRUCTURE:
> The FreeBSD files imported to RTEMS are placed under cpukit/libfreebsd/freebsd
> They follow the same file structure as in FreeBSD ( COMMIT [1] ).
>
> I have also implemented a few structures to make porting from FreeBSD
> easier and reduce the amount of redundant code. These files are *currently*
> placed under cpukit/libfreebsd/rtems ( COMMIT [2] )
>
> The spec file for libfreebsd is objfreebsd.yml [3] with the following contents in the
> include path. We currently don't install anything.
> install: []
> includes:
> - cpukit/libfreebsd
> - cpukit/libfreebsd/freebsd
> - cpukit/libfreebsd/freebsd/sys
> - cpukit/libfreebsd/rtems
>
> The files discussed here have the following structure
>
> ti_pinmux.c, ti_pinmux.h, ti_cpuid.h are present under
> libfreebsd/freebsd/sys/arm/ti
>
> bus.c, device.h, bus.h are present under
> libfreebsd/rtems
>
> For full list of files please refer to [4]
>
> ISSUES:
> 1) Can't include headers present under libfreebsd in BSPs directory.
> For eg: I want to include ti_cpuid.h [5] in BSP directory but can't do so
> even though the path has been added to the spec file. [3]
> In beagle/bspstart.c:
> #include <arm/ti/ti_cpuid.h>
> throws an error even though the path has been added in the spec file.
>
Seb addressed this.

> 2) Is it possible to have two same files one in RTEMS and other in RTEMS-libBSD
> without collision? At least with different install paths?
> For eg: The openfirm.h in RTEMS under something like
> libfreebsd/dev/ofw/openfirm.h
> And the open in libBSD as it is done currently.
> So this way we can include the RTEMS variant with
> #include <libfreebsd/dev/ofw/openfirm.h>
>
This should be possible. However I see a few concerns with the idea:
1. if the location is ambiguous then which header gets picked up could
be system-specific based on how it handles include path searching.
2. is there a need to keep them in sync between rtems and libbsd?

> Thanks,
> Niteesh
>
> [1] https://github.com/gs-niteesh/rtems/commit/4e7b3cd7c3f8e6ea71f7a1e988562b0b7a5a540e
> [2] https://github.com/gs-niteesh/rtems/commit/dbad2319a153513d02e7c0ab290ac72c04a5a715
> [3] https://github.com/gs-niteesh/rtems/commit/5eac1348c1b2fe2fdc406a3e573b66885f6eb93e
> [4] https://github.com/gs-niteesh/rtems/tree/pinmux_rtems6/cpukit/libfreebsd
> [5] https://github.com/gs-niteesh/rtems/blob/a4859fe053482b0b6b09c01b28fd06027356f3be/bsps/arm/beagle/start/bsp-soc-detect.h#L36
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel