[fprime 2.0][cmake] target_link_libraries on PROJECT_NAME

[tumbleshack]

Hey there! I'm working with @legounicycler and @teddylambert on Georgia Tech's GT-2 mission (SSDL).

We're updating to fprime 2.0 (using fprime as a submodule) and are running into a cmake error when compiling for our ATmega128.

We previously made a call to target_link_libraries() on PROJECT_NAME to link in Arduino headers. On the new fprime, this call fails, since PROJECT_NAME is now a utility target. The full error is below.

The relevant fprime change seems to be here: https://github.com/nasa/fprime/blob/devel/cmake/API.cmake#L310-L313

We're not super familiar with cmake and have two questions:

• Does anyone know how to link files into the entire project? If someone knows of an example, a pointer would be awesome.
• How does the change enable "additional post-processing"? This question benefits our curiosity.

CC @SterlingPeet

Utility targets may not have link dependencies.

CMake 2.8.12 and lower allowed using utility targets in the left hand side
position of the ``target_link_libraries()`` command. This is an indicator
of a bug in user code.

[SterlingPeet]

@LeStarch : I borrowed the seemingly broken approach from your F Prime Community Arduino Library, did you need to tweak that? I can see my students are testing this out before I got a chance to do so.

[LeStarch]

Yes, I think arduino needs to be tweaked for v2.0.0. See explanation below.

[LeStarch]

To fix your code:

target_link_libraries("${PROJECT_NAME}_exe" .....)

The reason for this is we broke our Ref into two parts:

• "Ref" a deployment target that depends on dict, packaging, and depends on:
• "Ref_exe" an executable target and the item that needs to link with arduino.

We need a level at which to set dependence on system level processes (for example dict) while still building/updating when you do a top-level build. Breaking Ref into the above two pieces made the most sense.

We are revisiting this in v3.0.0, but that is still under development.

[LeStarch]

In case you are curious, we are considering the following in v3.0.0 (and moving forward):

1. Ref: executable
2. Ref_Top (topology module, system stuff).

Thus your "top level" is once again a binary, but the system items are broken out as a module (owning topology). That way:

Ref -> dict, Ref_top
dict -> Ref_top (system)

And we maintain a DAG dependency wise. This does imply we need to rework installation/package building, but that should be a separate item anyway (and should be managed at the fprime-util) level.

[LeStarch]

BTW good question, and good diagnostic. You were spot-on with the cause of the error.

[tumbleshack]

Thanks for the detailed reply! Linking to the _exe did the trick.

For curiosity:
Why does Ref need to depend on dict, packaging, etc?
What source code is in the Ref_exe executable? I.e. what does it do?

If there are some docs on this subject which I've overlooked, a pointer would be very helpful too.

[Joshua-Anderson]

Ref_exe - The actual executable of the F' deployment, built from the Top directory of your deployment.
Ref - The primary build target that depends on the exe target, along with the other targets needed to use the F' deployment. The Ref target depends on the dict target so that when you build an F' deployment you have a dictionary you can use to command it. Packaging is used to copy all the raw binaries and dictionaries of a deployment into a common build directory