out of source architecture stub generation with fprime-util impl

[DentOpt]

Hi,
I am having an out of source build:

build
ws_root
 - Fprime
 - Application
       -Topology        
 - Module1

I want to create the implementation stubs for Module1
(Module1ComponentImpl.hpp,Module1ComponentImpl.cpp)

However, if I am running fprime-util impl in the Module1 repo, it is failing because of the missing deployment directory
Could not detect deployment directory for: /home/ws_root/Module
I tried to give the deployment directory

fprime-util impl -d ../../build/bin/Linux
fprime-util impl -d ../../build/lib/Linux
fprime-util impl -d ../../build/ManagerMission

I also tried to give the build directory fprime-util impl -b /home/build
If I use the standard fprime-util generate and fprime-util build it's only stating

Scanning dependencies of target impl
Built target impl

But no stubs are build.

Did any of you already encounter this issue?

[Joshua-Anderson]

fprime-util needs a cmake project in either the current directory or a parent directory.

If /Application is your deployment, try running fprime-util impl -d /home/ws_root/Application inside your module directory. Often in cases like this where I have several directories, some of which contain F' components and some of which are F' deployments, I'll just I'll create a cmake project in the git root so that I can always run fprime-util commands like check without needing to point to the project deployment.

[Joshua-Anderson]

Take a look at F' itself for an example... there's a CMake project in the root that's just there to make it easy to build components and run the unit tests, then there are particular deployments like Ref and RPI that define their own cmake project that build that specific deployment

[DentOpt]

Hi,
Thank you for your help. I tried to follow your advice and moved the Topology and Cmake project definition to the root level :

build
ws_root
 -Topology  
 - Fprime
 - CmakeLists (including Cmake project() )
 - Module1
     - MyTypeSerializableAi.xml

Module 1 contains the type MyType.
If I build now using cmake in the build folder to build Module1

cd build/Module1
cmake ../ws_root/Module1
make 

Everything compiles and the generated files, e.g.

build/Module1/MyTypeSerializableAc.cpp

contain references as desired to

#include <Module1/MyTypeSerializableAc.hpp>

If however I use fprime-utils to build
cd ws_root/Module1

fprime-util generate
fprime-util build

As before, it generates the files e.g. build/Module1/MyTypeSerializableAc.cpp
but now contains different references (using the local reference ./ instead of Module1/...)

#include <./MyTypeSerializableAc.hpp>

which lead to the build error message is:
/Module1/MyTypeSerializableAc.cpp:1:10: fatal error: ./MyTypeSerializableAc.hpp: No such file or directory
1 | #include <./MyTypeSerializableAc.hpp>

Here the related build files:
CMakeLists.txt (in ws_root)

project(Application_ApplicationProcessingUnit C CXX)
cmake_minimum_required(VERSION 3.13)
set(FPRIME_PROJECT_ROOT   ${CMAKE_CURRENT_SOURCE_DIR})
set(FPRIME_FRAMEWORK_PATH ${CMAKE_CURRENT_SOURCE_DIR}/Fprime)
include("${FPRIME_FRAMEWORK_PATH}/cmake/FPrime.cmake")
include("${FPRIME_FRAMEWORK_PATH}/cmake/FPrime-Code.cmake")
add_fprime_subdirectory("${FPRIME_PROJECT_ROOT}/Module1/")
add_fprime_subdirectory("${CMAKE_CURRENT_LIST_DIR}/Topology/")

settings.ini
[fprime]

framework_path: Fprime
library_locations: Module1
default_toolchain: native
environment_file: 
ac_constants: 
config_directory: 

I assume that it's a dependency issue mixing settings.ini with CMakeLists. Any idea why the fprime-util and cmake workflow is not consistent in such a setup?

[Joshua-Anderson]

I should clarify - you should keep your topology and primary cmake project within your deployment as you had before. I'm recommending adding an secondary cmake project and settings.ini file to your projects root directory to save a little bit of pain when you're trying to directly build/test/impl components not within your deployment, like Module1 in the example above.

Here's a few tips:

• Set settings project_root to the root of your project. I.E. for your settings.ini in /Application, it would be project_root: .. Project root is used as the default include path for everything.
• You're using the libraries option when you probably don't want to. The libraries option is mostly intended for git submodules, which is a pretty unusual use case. When you're using git submodules, you don't know what path somebody including your submodules. I.E, if you have my_library with components my_library/utils/componentA and my_library/utils/componentB. Within the library itself you'd use include paths like utils/componentA. Then, if you use this library in another project, you could include it as a git submodule at /project_utils. Without adding /project_utils as a library in your settings.ini, it wouldn't compile because all the headers would be relative to your project root (I.E. /utils/componentA). By adding /project_utils it as a library, it's added as a separate include root, so when you include utils/componentA cmake would search for both /project_utils/utils/componentA and /utils/componentA.

Right now, you're adding a standalone component (Module1) as a library. That's messing up your impl generated include paths (hence why everything is <./Module1.....> and also unnecessary if you set your project root to the root of your project.

If you get stuck, take a look at a couple example projects using the external project structure:

• basic example: gps tutorial
• complex example with libraries: fprime-sphinx

Note that neither of these projects are doing what I suggest where you add a secondary cmake project and setting.ini file to the project root to make it easier to work with components outside of your deployment. The GPS tutorial is too simple and the fprime-sphinx is too complicated and has all it's external components in submodules. You'll kinda see what I'm talking about in the fprime-sphinx-drivers repository though. This allows developers to standalone compile/unit test the drivers without needing to build the entire fprime-sphinx demo application.

[DentOpt]

Thank you Joshua for your suggestions. Also with the top level Cmake project, I have the same issue.
Unfortunately, I have exactly the problem you stated. Module1 is a git submodule that should not live in the namespace of the Application. So I need to add this here as separate library. Do you suggest any workflow for an "out of application build (git submodules)" of components using the fprime-util impl?

[LeStarch]

@DentOpt the issue is this: library_locations: Module1. This expects the Module1 to be a library containing modules. You are missing a folder for your library. Try something along the following:

settings.ini:

library_locations: path/to/my_library

Directory paths:

my_library
    Module1

I might further recommend the following: add a namespace directory to your subrepo:

<my_library's repo root>
    my_library
        Module1

I know this seems redundant to have the my_library root contain a folder also called my_library but this is important because now your includes and imports look like this:

#include <my_library/Module1/....>

Now you are free to include a Module1 component in multiple different libraries, and safely manage all of them as they are namespaced with the library name. See the following repo as an example. Note: it also contains a sample app alongside the library which uses it, but is outside the library namespace folder as it is not formally part of the library itself.

https://github.com/fprime-community/fprime-arduino