New Build System: Can't include headers

Thu Jul 2 13:03:45 UTC 2020

Hello,

This is a follow-up message since activity on this thread has stopped a
couple of days ago.

Thanks,
Niteesh.

On Tue, Jun 30, 2020 at 1:49 AM Niteesh G. S. <niteesh.gs at gmail.com> wrote:

> On Mon, Jun 29, 2020 at 8:59 PM Gedare Bloom <gedare at rtems.org> wrote:
>
>> 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.
>>
>
> How will the path be ambiguous if they are installed into two different
> sub-directories?
> Say we install the RTEMS variant of openfirm.h in
> $PREFIX/libfreebsd/dev/ofw. This
> way we can include it using #include <libfreebsd/dev/ofw>
> And we install the RTEMS-libBSD variant in its original directory which I
> guess ( not really sure)
> is $PREFIX/dev/ofw/openfirm.h.
> The files are in two different subdirectories, will this still be
> ambiguous?
>
> 2. is there a need to keep them in sync between rtems and libbsd?
>>
>
> I don't really understand what you mean by sync. If it is about
> maintaining the same file structure
> as in libbsd, then it depends on the use case.
>
> For example,
> For some files, it doesn't matter. An example is OpenFirmware functions.
> We can install the RTEMS
> variant to any directory as long as it doesn't collide with the libBSD
> variant.
>
> But in case of the pinmux driver, we will be porting it to RTEMS and will
> be removing it from libBSD
> in this case, it is really important to make sure we install it in the
> right directory i.e. maintain the same
> structure as it was in libBSD or else we will break things in libBSD.
> I am sorry if I misunderstood something.
>
> Thanks,
> Niteesh.
>
>
>
>> > 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200702/b901c20e/attachment.html>