rtems-libbsd build error

[Vijay Kumar Banerjee]

Doing a make for all, I'm getting this not found error ...
............
make: freebsd-org/contrib/libpcap/gen_version_header.sh: Command not found
make: *** [Makefile.todo:277: freebsd/contrib/libpcap/pcap_version.h] Error
127
.............

But it successefully builds the .m files into .c and .h files (I haven't
edited the Makefile yet).
after the make, if I try to ./waf it, it gives this error ...
==========
In file included from ../../rtemsbsd/include/machine/bus.h:781:0,
                 from ../../rtemsbsd/include/machine/_bus.h:1,
                 from ../../freebsd/sys/sys/bus.h:35,
                 from ../../rtemsbsd/local/usb_if.c:17:
../../rtemsbsd/include/machine/bus_dma.h:44:2: error: #error "the header
file <machine/rtems-bsd-kernel-space.h> must be included first"
 #error "the header file <machine/rtems-bsd-kernel-space.h> must be
included first"
  ^~~~~
../../rtemsbsd/local/usb_if.c:18:10: fatal error: usb_if.h: No such file or
directory
 #include "usb_if.h"
          ^~~~~~~~~~
compilation terminated.

==========
it seems like it's not changing it to #include <rtems/bsd/local/usb_if.h>.
Is it supposed
to be done manually by opening each file or am I missing a script?

On Mon, Apr 1, 2019 at 7:32 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:

> Am 01.04.19 um 15:29 schrieb Vijay Kumar Banerjee:
>
> [...] (I removed some of the discussion to make it more readable)
>
> >
> >     If you use the fb and framebuffer headers from RTEMS, you will get an
> >     RTEMS interface. The RTEMS based console code will work fine. But it
> >     might would be the solution where more work is necessary to port
> other
> >     applications or libraries. It seems that we have some libs already
> (like
> >     nano-X: https://devel.rtems.org/wiki/GSoC/2009/Wrapup) so I would
> be OK
> >     with that.
> >
> >     The other alternative would be to use the FreeBSD code that does the
> >     same. I'm not sure whether they call it framebuffer or something
> else.
> >     But I would expect that there is something similar. In that case it
> >     might would be simpler to port graphics libraries that already work
> on
> >     FreeBSD.
> >
> >     Both ways could be nice. I'm really not sure which one I would
> prefer.
> >     The first one is better integrated into the existing RTEMS ecosystem.
> >     The second one promises a wider world. So either take the one that
> >     interests you more or just use the one that looks simpler ;-)
> >
> > I will take the 2nd path and use the codes from freebsd fb. In the
> > forked branch
> > I have imported them along with the iic souce files just to make sure
> > that it builds.
> > I have also added the driver references in the nexus-device.h
> > I have a few questions/doubts before moving on to creating a fresh
> > branch to import
> > the file cleanly so that porting work can be started.
> >
> > There are a lot of files that are imported and out of them some were .m
> > files that
> > I built manually with the awk scripts and imported using the libbsd.py .
> > It seems like those
> > will need a cleanup and will need to be added to the Makefile.todo (?)
>
> Most likely Makefile.todo is currently the right place. Also in long
> term it should move to waf. But that's out of the scope of your project.
>
> >
> > Will the whole thing be one big patch? or will it be done in chunks of
> > the subdirectory
> > like videomode headers and souce imported in one patch, fb in another ?
>
> I think I already have made a note at your proposal: I would suggest to
> split it up in smaller functional blocks. That even allows to merge
> small parts during the GSoC instead of having one big block at the end.
> But please note that all parts should be useful and every commit in
> libbsd (and in RTEMS) must be compilable. Otherwise (useful) tools like
> `git bisect` won't work.
>
> So if you have functional groups: Split it up. If a big block is
> necessary because the small parts can't work on their own: Keep it in
> one import + one port commit.
>
> >
> [...]
>
>
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax:   +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190401/93c04195/attachment-0001.html>