Configure Cmake Build - Error : Could NOT find Plantuml (missing: PLANTUML_VERSION)
Closed, ResolvedPublic
Actions

Description

Cmake : 3.10.2
Linux : Ubuntu 18.04

Command

cmake ../ -G"Unix Makefiles" -DTARGET_PLATFORM=MUSCA_A -DCOMPILER=ARMCLANG

When following software requirements, and setting

export PLANTUML_JAR_PATH="~/plantuml/plantuml.jar"

It reports..

-- Could NOT find Plantuml (missing: PLANTUML_VERSION) 
CMake Warning at cmake/Common/BuildSphinxDoc.cmake:59 (message):
  Some tools are missing for Sphinx document generation.  Document generation
  target is not created.
Call Stack (most recent call first):
  cmake/Common/BuildSphinxDoc.cmake:65 (SphinxFindTools)
  secure_fw/CMakeLists.txt:23 (include)

Although If i set:
export PLANTUML_JAR_PATH="/home/<user>/plantuml/plantuml.jar"
It seems to solve this issue.

Problem could be here.

Event Timeline

jainvikas8 created this task.Aug 22 2019, 5:35 PM

Summary:

It is wrong to set PLANTUML_JAR_PATH as export PLANTUML_JAR_PATH="~/plantuml/plantuml.jar" and instead export PLANTUML_JAR_PATH=~/plantuml/plantuml.jar shall be used (Note: quotation marks removed).

Details:

The ~ character has a special meaning only to the shell. If you call any executable with a path relative to ~, then tile file operations will fail as the kernel is not able to convert ~ to your home path (see http://man7.org/linux/man-pages/man2/open.2.html and http://man7.org/linux/man-pages/man7/path_resolution.7.html).

Investigation steps:

I re-created the error on a a Linux Mint 19.1 machine by moving the plantuml.jar file to my home directory and setting the environment variable to point to it, ensuring the environment variable has the ~ character inside. Then I ran cmake against the current tip of the master branch. This lead to the same error as reported by @jainvikas8 .
I modified FindPlantuml.cmake to output the the java command used to get plantuml version. This seems to be /usr/bin/java -jar "~/plantuml.jar" -version and it reports Error: Unable to access jarfile ~/plantuml.jar
Removing the quotation marks solved the issue. This results in the shell resolving ~ to the full path of the home directory. Thus the full path will be passed to java as a parameter.
I checked how cat behaves with and without quotation marks, and found the same behavior.
The I run strace /usr/bin/java -jar "~/plantuml.jar" -version to see what file operations were executed, and found this line in the strace output openat(AT_FDCWD, "~/plantuml.jar", O_RDONLY) = -1 ENOENT (No such file or directory). So the ~ relative path was passed to the kernel which failed to resolve it.
Then I checked the documentation and confirmed the Kernel behavior is matching the documentation. (Note: in the details section I link to the man page of open and not openat, but the two system calls use the same pathname parameter type and look up the path the same way.)

Based on my investigations this is not a bug and no fix is needed.

Hi @gyuri-szing,

The documentation https://git.trustedfirmware.org/trusted-firmware-m.git/tree/docs/user_guides/tfm_sw_requirement.rst defines exporting PLANTUML_JAR_PATH including the double quotes. The issue is valid and the documentation needs fixing.

Thanks,
Dev

That's a valid point, the documentation needs to be fixed.

I'm happy to create a patch set for it.

@jainvikas8: Thank you for volunteering! Please create a patch to fix the documentation.

This task is sorted - https://review.trustedfirmware.org/c/trusted-firmware-m/+/1811 and can be closed.

Fix has been merged.