Reimplement impl with fpp-to-cpp

[thomas-bc]

Originating Project/Creator
Affected Component
Affected Architectures(s)
Related Issue(s)
Has Unit Tests (y/n)
Builds Without Errors (y/n)
Unit Tests Pass (y/n)
Documentation Included (y/n)

---

Change Description

Implements nasa/fprime#2204

fprime-util impl [--ut] now uses fpp-to-cpp instead of the Python autocoders (through cmake)
Also uses the same interface to run the implementation after fprime-util new --component

Also some small changes to help text here and there.

[thomas-bc]

Review comments

[LeStarch]

There are two issues with this PR:

1. Running fprime-util impl --ut does not produce .template files, and thus will clobber the existing UT files
2. The imports aren't working for the SignalGen UT
3. The import for Ref/SignalGen/SignalGen.hpp comes out as SignalGen/SignalGen.hpp
4. The import in SignalGenTestMain.cpp isn't using a relative import, and thus cannot find SignalGenTester.hpp

These both might be issues in FPP (@bocchino, thoughts?)

[thomas-bc]

(1) fprime-util impl --ut does not mess with filenames. Currently it seems FPP generates <filename>.template for fpp-to-cpp, but regular <filename> for fpp-to-cpp --templates. I can implement the file renaming, but we may want to implement that in FPP instead?
(2) and (3) are an oversight on my end - I forgot to test with the old project structure (e.g. Ref/)
(4) Not too sure there, may be related to (2) and (3), I'll investigate

[LeStarch]

@thomas-bc:
(1) We should implement it in fpp
(4) This is likely an issue in FPP as I fixed a similar issue in fpp's Tester.cpp

[bocchino]

Running fprime-util impl --ut does not produce .template files

We can change this, but the way it works in FPP now is consistent with the way it works in XML and has always worked.

and thus will clobber the existing UT files

I don't think so, because the existing UT files are typically in test/ut and the generated files are in the component directory. This way the user can just copy the files over, without renaming files. It is inconsistent with the .template naming for the flight implementation, but it seems to work well based on experience so far.

[bocchino]

This is likely an issue in FPP as I fixed a similar issue in fpp's Tester.cpp

I agree, I'll open an issue to fix it in FPP.

[bocchino]

Is now a good time to make a v2.0.1 release of FPP to get these changes into F Prime mainline?

[LeStarch]

Just two comments!

[LeStarch]

Why? Also, this should not use "cmake root", but build.get_settings("project_path") should it not?

[thomas-bc]

Yes absolutely, my mistake. By using project_root, we don't need to check whether the build structure is old or new, as project_root and framework_path will simply be the same. Note, both of these values are guaranteed to exist as per the following:
https://github.com/fprime-community/fprime-tools/blob/4fc88dc0a20fcadd5b09bb5a188bc41373237d5d/src/fprime/fbuild/settings.py#L52-L53

since find_fprime will error out if it can't find framework_location

[LeStarch]

Left two more comments.