Replies: 2 comments 10 replies
-
|
This issue seems to be related: #280. |
Beta Was this translation helpful? Give feedback.
-
|
The cFS repo was originally created to provide a sample set of submodules that work together and for CI (and an easy quickstart/example). Really all you need is cfe/psp/osal within the context of your project (and your customized *_defs, whatever apps you want, etc). There was actually a significant amount of debate related to setting up cFS as a monorepo vs submodules, which we really only got around by considering the cFS repo as an "example"... projects are free to start from it or create their own monorepo or whatever. The intent wasn't for cFS to be taken as is and exist as a submodule within a project... which is why it ends up being a bit unfriendly to manage that way. |
Beta Was this translation helpful? Give feedback.
-
|
We have something similar. We created our cmake build system before the NASA cmake build system was made public, and we still use ours. We support many different projects, using different CFS versions and components, and need to have many different project repositories but be able to push and pull updates from the common repositories. We also need to accommodate mixing public and proprietary code (apps, OSALs, PSPs, configurations, even forked CFE repos). Our build system puts no constraints on where OSALs, PSPs, application code, tables, platform header files, or mission header files reside. We have a repository at https://github.com/windhoverlabs/baseliner, that creates our initial CFS project repository. There is an input file where you specify the repository URLs and the commit/branch/tag you want to pull in for CFE, OSALs, PSPs, applications, and tools, and whether you want them as git modules or subtrees. After you run the script, you push the newly created project to its new CM project. We used that to create our https://github.com/windhoverlabs/airliner public repository, and repositories for other projects. Some of the builds in that public repository require proprietary OSALs, PSPs, and applications. Those are in private repositories, so those builds fail if one does not have access to the private repos. The public builds still build though. All components are relocatable, but our typical project structure is: <main_private_repo>/public/ <- This is the Airliner repo at https://github.com/windhoverlabs/airliner <main_private_repo>/private/apps <- Proprietary or non-public applications <main_private_repo>/... <- Non CFS stuff like drivers, OS, IP, etc... My recommendation is to not be afraid to change the build system and be creative with where to put files to better fit your CM policies and work flow. Most of the code is independent of the build system. Version 6.7 did add some build system auto-generated code, but those are relatively easy to recreate. Lastly, I have also occasionally created totally different build structures to accommodate vendor specific build systems, i.e. Wind River Workbench, Green Hills Multi, Xilinx SDK, and Xilinx Vitis. Green Hills works out well because build configuration is inheritable, making it easier to maintain, particularly for ARINC653 builds. Workbench allows nested projects but configuration doesn't inherit so its difficult to maintain. Xilinx SDK requires a lot of work. Vitis was a total show stopper. |
Beta Was this translation helpful? Give feedback.
-
Yeah, but without modifying the cFE cmake infrastructure, it still needs to be in a very specific location. The exact coupling I'm referring to is the explicit dependency on add_subdirectory(${MISSION_SOURCE_DIR}/tools tools)
# Add a dependency on the table generator tool as this is required for table builds
# The "elf2cfetbl" target should have been added by the "tools" above
add_dependencies(mission-prebuild elf2cfetbl)
Indeed. Being able to leverage all the work that's gone into the EDS tooling including Edit: Changed source link to permalink |
Beta Was this translation helpful? Give feedback.
-
|
@jbohren-hbr - I'm in favor of relaxing assumptions where possible, especially if we can reduce some of the "magic" that is baked into the current setup. Side note - there are rumors of a possible generic EDS related tool in work that could import/export EDS as well as associated binary files, support editing, visualization, etc. The idea is it would support tables (generation/loads and dumps) as well as the binary "cFS files" that are produced by cFS as long as there is an associated data sheet, and hopefully be able to convert between the representations along w/ a simple editor/visualizer. Other folks are working this so I may be out of date on the details or status (and the concepts may have evolved since my request/involvement). |
Beta Was this translation helpful? Give feedback.
-
|
Would creating a new cmake parameter, say |
Beta Was this translation helpful? Give feedback.
-
Yeah, that's an approach that would relax the requirements on workspace layout in the near term. From a dependency / scope standpoint, the |
Beta Was this translation helpful? Give feedback.
-
|
I opened nasa/cFE#1907 and one of our community members tried one approach to addressing it with nasa/cFE#1910. We're still on the fence whether to do a halfway solution or wait until cFS-Draco to implement something more fully fleshed out. Regardless, please check those out and add your thoughts. |
Beta Was this translation helpful? Give feedback.
-
Hello everyone,
We would like to know what a typical cFS-based project structure should look like.
It looks like cFS directory structure assumes that the user apps should be created in the CFS_ROOT/apps directory which means that they should live inside a fork of the main cFS repository.
One alternative for us could be a vendor directory-based approach with the following structure:
Project root:
On a previous project, we could achieve the vendor-based structure but it required serious CMake surgery on the normal cFS CMake files, and this was something we would like to avoid in the future.
The reasons why the out-of-source approach seems more attractive to us:
Is there a way we could achieve this out-of-cFS-source-tree configuration with the current cFS CMake structure? Also, does this approach seem reasonable?
Thank you for your attention.
Beta Was this translation helpful? Give feedback.
All reactions