Viewing 1 post (of 1 total)
  • Author
  • #1267


    Could we consider possibly adding a coding standard to the CFS development plan to require that CFS source code is decoupled from external tools like cmake and EDS? I work many different CFS based projects with multiple different organizations and companies. Everybody views the source code as being sealed with a certain degree of pedigree, but very few use the NASA provided Makefile or CMake build system as is. In some cases, the flight software is just one small piece in a much larger system of systems. I usually end up writing a custom Makefile or CMake build system to better integrate the build with their processes. Until recently, CFS fit well because there was no dependency on external tools and we were free to use whatever toolchain and process fit our needs. I ported CFS to a proprietary system that included a custom non-makefile or cmake build system with no problem. I’ve created projects with build systems managed by Eclipse, Wind River Workbench, Xilinx XSDK, Jetbrains CLion, even Rational Rhapsody. I’ve completely rearranged the directory structure to meet customer data and code management requirements. All of which was relatively easy to do with CFS. However, with the latest releases this has started to change. I’m seeing dependencies on cmake in the source code itself, particularly in the “enhanced build” changes. For example, some OSALs now have a line that reads:

    “#define CFE_PSP_RESET_AREA_SIZE (GLOBAL_CONFIGDATA.CfeConfig->ResetAreaSize)”

    That GLOBAL_CONFIGDATA object is created as part of the cmake enhanced build system. CFE_PSP_RESET_AREA_SIZE used to be a macro that was defined in a header file. I rewrote the CFS documentation system several times to auto generate documentation which included macros like this. This recent change would have required changes to source code to use the build system the customer requested, or changes to the documentation system to continue generating all the documentation using the prepackaged build system. In the example above, you can also setup cmake to auto generate the header file. Those that don’t use cmake can still use the existing header file. Those that use Doxygen can still generate documentation from it. Those that have other methods to auto generate build time configuration can continue generating that header file as they already were.

    I’ve been hearing that CFS is pushing to use EDS. My concern here is that not all of the CFS users have EDS and not everybody will want to use it. I haven’t seen a dependency on EDS in source code yet, but when it happens its going to be a problem for those of us that don’t have it or don’t want to retool our process just because somebody up stream prefers EDS.

    Please take serious consideration with this request. I love working with CFS because the design and code implementation stands all by itself, allowing me to easily port it to countless platforms and integrate it with many toolchains and build processes, making me look like the super genius software engineer that I like to think I am. But I’m seeing CFS taking a turn that other frameworks have taken, some of which ended up with bloated inflexible one-size-fits-none that are unwieldy to deploy and difficult to port.

    If I misunderstood the new cmake changes, I apologize. The new changes took me by surprise and I had to quickly adapt without taking the time to explore all possible solutions. I haven’t taken the time to fully study the NASA supplied cmake build system since, until now, I was able to continue using the cmake build systems I had already created. Please let me know if there’s a better solution.

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.