On 25/8/20 12:34 am, Heinz Junkes wrote: > Thanks Chris for the explanation. It all makes sense.
My pleasure. > I stumbled over the following point: > > I tested the rc-2 and followed the Quick Guide to Building. > “ > To build the tools for the ARM architecture: > > ../source-builder/sb-set-builder \ > --prefix=$HOME/development/rtems/5.1-rc2 \ > 5/rtems-arm > > To build the tools, kernel and all packages for the Beagleboneblack: > > ../source-builder/sb-set-builder \ > --prefix=$HOME/development/rtems/5.1-rc2 \ > 5/bsps/beagleboneblack > “ > > After that I tried to build EPICS and ran into the error of a missing header > file. > “librtemsNFS.h could not be found” > This header file is in rtems-libbsd which I then had to reinstall and build > for the target. I could not find `librtemsNFS.h` but I found `librtemsNfs.h`? ... $ find . -name librtems\*.h ./cpukit/libnetworking/librtemsNfs.h > > Then I thought about whether a recipe could/should consider this dependency. > The header should be there. I am more concerned about the contents of the that header ... hmm. What calls does EPICS use from this file? I suggest it gets reviewed. The problem RTEMS has long term with the interface in `librtemsNfs.h` is it being bespoke to the NFS implementation and we may not be able to maintain it in the future, for example upgrading NFS to NFSv4. In systems I work on for clients I encourage scripting of some form be used. Commands hide the implementation details and this lets us (RTEMS) better maintain compatibility. The scripting can be plain text files or `joel` scripts or command sequences in another configuration format, for example YAML. You can directly call shell commands. To mount a remote disk use: mkdir /foobar mount -t nfs foo:/bar /foobar Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel