Resolution of File Locations Does Not Respect Symbolic Links

[LeStarch]

https://github.com/fprime-community/fpp/blob/63799b4b1fbe57db87f9445d7a31fc5ff1c2d2da/compiler/lib/src/main/scala/codegen/CppWriter/CppWriterState.scala#L45

See discussion below

By calling .normalize after .toAbsolutePath causes links to resolve into a "real path". When F´  is building within a symlinked directory this causes incorrect include paths to be generated because removeLongestPathPrefix does not deal in realpaths and thus does not strip off the prefix when it should.

It is recommended that .normalize be removed in the above call, and all uses of .normalize should be reviewed.

[LeStarch]

This is not the issue, it seems to be dependent on the working directory.

[LeStarch]

The issue comes from the use of working directory to generate path names.

java.nio.file.Paths.get(fileName)

When filename does not contain a path (just a name) then Java prepends the working directory name. However, the JVM resolves symlinks at startup when determining the working directory name. Thus paths generated with the above will always resolve paths and thus fail on symlinks.

The only way to fix this would be to pass in the working directory as an argument to the process and use that instead of Java's understanding of the working directory.

Since Scala is dependent on the JVM it is limited by the same flaws. Theoretically python has the same issue.

[bocchino]

I looked at the underlying issue nasa/fprime#1604. I think the issue is that when we run fpp-to-xml foo/bar.fpp, and foo is a symlink to baz, the location of the input file becomes baz/bar.fpp instead of foo/bar.fpp.

If this is correct, then I see two ways to fix it: (1) get the FPP locations to respect the symlinks or (2) provide the -p input with regard to the real path names (in addition to they symlinked path names).

[bocchino]

When the file name string comes in on the command line, it gets converted to an FPP file here:

https://github.com/fprime-community/fpp/blob/63799b4b1fbe57db87f9445d7a31fc5ff1c2d2da/compiler/lib/src/main/scala/util/File.scala#L61

If the file names being passed in on the command line are relative to the working directory, then the JVM resolution of the working directory would be an issue here. If that's the case, then the following could also fix it: (3) don't use relative file path names, e.g., run fpp-to-xml $PWD/foo/bar.fpp instead of fpp-to-xml foo/bar.fpp.

[LeStarch]

After thinking on this more, I believe the correct fix is to have CMake, which calls into FPP, respect the resolved paths that the JVM deals in. Thus I will add an issue over there!

[LeStarch]

Closing in favor of: nasa/fprime#2455

[bocchino]

Sounds good! I opened an issue to document this idiosyncrasy in the User's Guide. See #371.