New Build System: Can't include headers
Niteesh G. S.
niteesh.gs at gmail.com
Thu Jul 2 13:03:45 UTC 2020
This is a follow-up message since activity on this thread has stopped a
couple of days ago.
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>
>> > 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
>> > 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
>> > They follow the same file structure as in FreeBSD ( COMMIT  ).
>> > I have also implemented a few structures to make porting from FreeBSD
>> > easier and reduce the amount of redundant code. These files are
>> > placed under cpukit/libfreebsd/rtems ( COMMIT  )
>> > The spec file for libfreebsd is objfreebsd.yml  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 
>> > ISSUES:
>> > 1) Can't include headers present under libfreebsd in BSPs directory.
>> > For eg: I want to include ti_cpuid.h  in BSP directory but can't do
>> > even though the path has been added to the spec file. 
>> > 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
>> > 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
> 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
> 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
> 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
>> > 
>> > 
>> > 
>> > 
>> > 
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the devel