Incorrect header include when built in a syminked directory

[myint]

F´ Version	776af78
Affected Component	N/A

---

Problem Description

Due to issues with Java/Scala and the FPP tool-set. It becomes a question as to whether we need to support symlinks outside fprime-util which resolves to the full corrected path.

Converted this issue into an epic:

• Incorrect use of REALPATH in cmake normalize_paths: CMake System Uses REALPATH in normalize_paths Incorrectly #2449
• Incorrect normalization of paths loaded in ini_settings: ini-to-stdio.py Returns Real Paths #2450
• Incorrect topology includes: Resolution of File Locations Does Not Respect Symbolic Links fpp#370
• CMake Should Convert to Canonical Path When Handing Arguments to FPP #2455
• Fix Packet Autocoder For Symlinked Paths: Packet Autocoder Generates Bad Includes on Symlinked Paths #2453
• Add CMake UT To Test Symlinked Builds #2624

Further description

If I clone/build fprime in a symlinked directory, I get the following build error. The error goes away if I clone/build it in a non-symlinked path.

[ 13%] Building CXX object F-Prime/Fw/Log/CMakeFiles/Fw_Log.dir/LogPortAc.cpp.o
cd /data/rps/myint/fprime-hce/build/F-Prime/Fw/Log && /usr/bin/c++  -DFW_BAREMETAL_SCHEDULER=0 -DTGT_OS_TYPE_LINUX -I/data/rps/myint/fprime-hce/build -I/data/rps/myint/fprime-hce/build/F-Prime -I/data/rps/myint/fprime-hce -I/data/rps/myint/fprime-hce/config -I/data/rps/myint/fprime-hce/Fw/Log -I/data/rps/myint/fprime-hce/Fw/Com -I/data/rps/myint/fprime-hce/Fw/Time -I/data/rps/myint/fprime-hce/Fw/Port -I/data/rps/myint/fprime-hce/Fw/Cfg -I/data/rps/myint/fprime-hce/Fw/Types -I/data/rps/myint/fprime-hce/Fw/Logger -I/data/rps/myint/fprime-hce/Fw/Obj -I/data/rps/myint/fprime-hce/Fw/Tlm -isystem /data/rps/myint/fprime-hce/Fw/Types/Linux  -Wall -Wextra -Werror -Wold-style-cast -Wno-unused-parameter -std=c++11 -DASSERT_FILE_ID="0xdacc024b" -o CMakeFiles/Fw_Log.dir/LogPortAc.cpp.o -c /data/rps/myint/fprime-hce/build/F-Prime/Fw/Log/LogPortAc.cpp
In file included from /data/rps/myint/fprime-hce/build/F-Prime/Fw/Log/LogPortAc.cpp:6:0:
/data/rps/myint/fprime-hce/build/F-Prime/Fw/Log/LogPortAc.hpp:20:72: fatal error: /var/ammos/rps/myint/fprime-hce/Fw/Log/LogSeverityEnumAc.hpp: No such file or directory
 #include </var/ammos/rps/myint/fprime-hce/Fw/Log/LogSeverityEnumAc.hpp>
                                                                        ^
compilation terminated.
make[2]: *** [F-Prime/Fw/Log/CMakeFiles/Fw_Log.dir/LogPortAc.cpp.o] Error 1
make[2]: Leaving directory `/var/ammos/rps/myint/fprime-hce/build'
make[1]: *** [F-Prime/Fw/Log/CMakeFiles/Fw_Log.dir/all] Error 2
make[1]: Leaving directory `/var/ammos/rps/myint/fprime-hce/build'
make: *** [all] Error 2

The incorrectly autocoded LogPortAc.hpp:

/*
 * LogPort.hpp
 *
 *  Created on: Monday, 01 August 2022
 *  Author:     myint
 *
 */
#ifndef FW_LOG_PORT_HPP_
#define FW_LOG_PORT_HPP_

#include <cstring>
#include <cstdio>
#include <FpConfig.hpp>
#include <Fw/Port/InputPortBase.hpp>
#include <Fw/Port/OutputPortBase.hpp>
#include <Fw/Comp/PassiveComponentBase.hpp>
#include <Fw/Types/BasicTypes.hpp>
#include <Fw/Types/Serializable.hpp>
#include <Fw/Types/StringType.hpp>
#include </var/ammos/rps/myint/fprime-hce/Fw/Log/LogSeverityEnumAc.hpp>
#include </var/ammos/rps/myint/fprime-hce/Fw/Log/LogBuffer.hpp>
#include <Fw/Time/Time.hpp>


namespace Fw {
...

How to Reproduce

1. Create a directory.
2. Create a symlink to the above directory.
3. cd into the above symlink.
4. Clone fprime.
5. Build it.
6. Get a build error due to an incorrect header include.

Expected Behavior

I would expect no build error and I would instead expect the autocoder to instead generate the following for LogPortAc.hpp. I can make the above autocoding error go away by directly cding into the resolved directory rather than the symlinked path:

/*
 * LogPort.hpp
 *
 *  Created on: Monday, 01 August 2022
 *  Author:     myint
 *
 */
#ifndef FW_LOG_PORT_HPP_
#define FW_LOG_PORT_HPP_

#include <cstring>
#include <cstdio>
#include <FpConfig.hpp>
#include <Fw/Port/InputPortBase.hpp>
#include <Fw/Port/OutputPortBase.hpp>
#include <Fw/Comp/PassiveComponentBase.hpp>
#include <Fw/Types/BasicTypes.hpp>
#include <Fw/Types/Serializable.hpp>
#include <Fw/Types/StringType.hpp>
#include <Fw/Log/LogSeverityEnumAc.hpp>
#include <Fw/Log/LogBuffer.hpp>
#include <Fw/Time/Time.hpp>


namespace Fw {
...

[myint]

I traced the problematic absolute paths up the dependency chain to build/F-Prime/Fw/Log/LogPortAi.xml. This is generated by fpp-to-xml, which is a binary blob. So my tracing stopped there.

<?xml version="1.0" encoding="UTF-8"?>

<!-- =====================================================================
LogPortAi.xml
Generated by fpp-to-xml
====================================================================== -->
<interface namespace="Fw" name="Log">
  <comment>
  Event log port
  </comment>
  <import_enum_type>/var/ammos/rps/myint/fprime-hce/Fw/Log/LogSeverityEnumAi.xml</import_enum_type>
  <include_header>/var/ammos/rps/myint/fprime-hce/Fw/Log/LogBuffer.hpp</include_header>
  <include_header>Fw/Time/Time.hpp</include_header>
  <args>
    <arg name="id" type="FwEventIdType">
      <comment>
      Log ID
      </comment>
    </arg>
    <arg name="timeTag" type="Fw::Time" pass_by="reference">
      <comment>
      Time Tag
      </comment>
    </arg>
    <arg name="severity" type="Fw::LogSeverity">
      <comment>
      The severity argument
      </comment>
    </arg>
    <arg name="args" type="Fw::LogBuffer" pass_by="reference">
      <comment>
      Buffer containing serialized log entry
      </comment>
    </arg>
  </args>
</interface>

[LeStarch]

@myint this may be an issue in the build system. We try to determine the relative PATHs of files by taking the absolute path and removing a prefix. My guess is that:

1. The above absolute paths have "resolved" the link in the directory tree
2. The prefix is un-resolved

Thus to the build system they look to be completely separate path hierarchy and it falls back to using full paths to objects rather than the relative path like you see in Time.hpp.

[LeStarch]

The fix is to ensure that all paths either resolve links, or do not resolve links....but not a mixture.

[LeStarch]

The build works correctly, today, using fprime-util. This is because that resolve()s all links and builds in the original path. This is not necessarily desired, but functions.

To reproduce real errors, build with cmake directly:

cd /linked/fprime/Ref
mkdir build
cd build
cmake ..

This produces an error as the config directory (as loaded from the settings.ini) is resolved and thus cannot be found within the build.

Correcting that with:

cmake .. -DFPRIME_CONFIG_DIR=../../config

Reproduces the error here.