Hi Chris, minor update on the progress.
I managed to start the compilation correctly on Friday. Of course it fails as the source needs to be modified. On that front I haven't heard back from people responsible for the ethernet driver and if libbsd is in their scope. In general which are the options? Libbsd and standard RTEMS networking stack? I will try to evaluate both and have something compiling by Friday hopefully, so I can test and create the patches. Cheers, Niko On Thu, Sep 7, 2017 at 5:40 PM, Nicolas Tsiogkas <lou.n...@gmail.com> wrote: > Thanks Chris for your input. > > I think I've used a cmake gui once in 2008 or 2009 and never did that to > myself again. :P > > I started creating the required cmake extensions for SOEM. I hope to have > something trying to compile by monday sometime. I'll keep you posted. > > Cheers, > Niko > > On Thu, Sep 7, 2017 at 3:57 AM, Chris Johns <chr...@rtems.org> wrote: > >> On 06/09/2017 19:56, Nicolas Tsiogkas wrote: >> > I'm trying to integrate SOEM with RTEMS (https://devel.rtems.org/ticke >> t/3120 >> > <https://devel.rtems.org/ticket/3120>) >> >> Thank you for creating the ticket. >> >> > As I am trying to create the appropriate bset and cfg files I noticed >> that all >> > the packages built are based on autoconf to be built. >> >> This reflects the nature of the packages we currently support and nothing >> more. >> >> > SOEM on the other hand is only providing CMake as a build tool. >> >> This should be fine if the implementation in SOEM is ok. >> >> > I have found instructions on using CMake with RTEMS >> > (https://lists.rtems.org/pipermail/devel/2016-March/013800.html) >> > >> > The question is if it would be more sensible to create a build >> environment for >> > SOEM based on autotools or try to use CMake somehow? >> >> I do not think there is a need. The upstream project has selected cmake >> and we >> should respect that. >> >> > I doubt that changing the build system will be easily accepted upstream. >> >> Agreed. >> >> The RSB scripts will invoke cmake so this bit is easy. The part you need >> to work >> with the upstream project is getting a cross-complier build to work. How >> well >> this works depends on how the cmake build scripts in the project are >> implemented. Carefully constructed cmake build scripts and the judicious >> use of >> the command line `-D` options can be used to configure and/or build the >> package. >> >> I should warn you, use the cmake gui and tui tool at your own risk, if >> you step >> in there you may never return as the same person. >> >> The key file in the RSB is rtems-bsp.cfg [1]. It wraps a private package >> config >> implementation that parses an installed BSP's build configuration [2] and >> updates the internal RSB data [3]. >> >> I suggest you get the package to build from the command line for a BSP. >> This >> will be the compiler name and cflags. What you end up with will be >> available in >> the macros in rtems-bsp.cfg. >> >> Have a look in the BSP installed .pc file for the flags to use, ie do a >> `find . >> -name \*.pc` from the RTEMS installed prefix path. >> >> My (publicly denied) cmake experience with RTEMS is configure header >> tests can >> be fragile if there is cmake nesting. >> >> Chris >> >> [1] https://git.rtems.org/rtems-source-builder/tree/rtems/config >> /rtems-bsp.cfg >> [2] https://git.rtems.org/rtems-source-builder/tree/rtems/config >> /rtems-bsp.cfg#n64 >> [3] https://git.rtems.org/rtems-source-builder/tree/rtems/config >> /rtems-bsp.cfg#n81 >> > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
