Am 01.04.19 um 16:38 schrieb Vijay Kumar Banerjee: > Doing a make for all, I'm getting this not found error ...
Just a note: The make for all shouldn't be necessary. But if you do it please have a very detailed look at what is changed. It should be nothing except the things you added. > ............ > make: freebsd-org/contrib/libpcap/gen_version_header.sh: Command not found > make: *** [Makefile.todo:277: freebsd/contrib/libpcap/pcap_version.h] > Error 127 > ............. Seems that this build step has been eliminated from libpcap. The pcap_version.h isn't included anywhere anymore. Maybe you can create and test a patch that removes the header freebsd/contrib/libpcap/pcap_version.h and the build step in Makefile.todo? > > 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. Please use `./waf -j1` to get only one error message. There are two messages mixed here. > > ========== > 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? That should be done by the freebsd-to-rtems.py script when you import the files. If it doesn't change these, you either have called it in a wrong way or the script has a bug. > > On Mon, Apr 1, 2019 at 7:32 PM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@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. > > > > [...] > > > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
