Buildbarn creates output directories based on the root directory

[Qinusty]

Buildbarn sets output directories relative to root directory as opposed to the working directory.

This can be seen here.

The RE protos (v2) specify that the working directory as:

  // The paths are relative to the working directory of the action execution.
  // The paths are specified using a single forward slash (`/`) as a path
  // separator, even if the execution platform natively uses a different
  // separator. The path MUST NOT include a trailing slash, nor a leading slash,
  // being a relative path. The special value of empty string is allowed,
  // although not recommended, and can be used to capture the entire working
  // directory tree, including inputs.
...
repeated string output_directories = 4;

  // The working directory, relative to the input root, for the command to run
  // in. It must be a directory which exists in the input tree. If it is left
  // empty, then the action is run in the input root.
string working_directory = 6;

This becomes an issue when the working directory is not specified as the input root and the output is specified as a subdirectory of the input directory outside of the working directory.

build_directory
├── input_root
└── output_dir

bb browser

Looking at an example action from a buildstream execution through the eyes of bb-browser shows the following buildbarn-buildstream.pdf

Buildstream specifies the working directory as /buildstream/autotools/hello.bst/doc/amhello whilst expecting buildbarn to provide ../../../../../ relative to the working directory as an output directory (which would be /).

Buildbarn seems to interpret this as ../../../../../ relative to /.

Required change

Specified paths:

• Working directory is relative to input root
• Output directories are relative to working directory

Current paths:

• Working directory is relative to input root
• Output directories are relative to input root

[EdSchouten]

Buildbarn sets output directories relative to root directory as opposed to the working directory.

I agree that this is an issue indeed.

build_directory
├── input_root
└── output_dir

This is the part that confuses me: under what circumstances would the input root not be the top level build directory? If this were allowed, what would the name of the input_root be? It wouldn't be provided as part of the build action, meaning the action would not be able to make any assumptions whatsoever to be able to find its input root.

[juergbi]

This is the part that confuses me: under what circumstances would the input root not be the top level build directory?

I don't think that's possible. The problematic structure is the following, as far as I can tell:

input_root
├── working_dir
└── output_dir

According to the spec, the output directory should be specified as ../output_dir. However, Buildbarn doesn't seem to support that.

[EdSchouten]

That said, one change we should consider making to Buildbarn at some point is that we do move the input root into some kind of subdirectory, reserving the top-level directory for other storage purposes. For example, stdout and stderr of build actions are currently stored as files inside the input root. So like this:

input_root
├── .stdout.txt
├── .stderr.txt
├── input_file.c
└── output_file.o

Though most build actions generally don't care about that, it's a bit sloppy. If a build action would try to tar its entire input root, it would also archive its own stdout/stderr logs. We should consider restructuring it to something like this:

build_directory
├── stdout.txt
├── stderr.txt
└── input_root
    ├── input_file.c
    └── output_file.o

[Qinusty]

Ah yes, @juergbi is correct there.

build_directory
├── input_root
└── output_dir

Was intended to be

build_directory
├── working_directory
└── output_dir

To address this issue, I propose that it is necessary to

• Fix the relative paths throughout buildbarn
• Allow clients to target the input root as an output directory through some means (preferably relative pathing via ..)

[Qinusty]

Whilst looking to fix this I ran into several issues due to restrictions in bb-storage around valid file path components. Due to being unable to specify "." as a parameter to Lstat, it is impossible to specify the input root as an output directory until #20 is addressed.

As to changing the relative pathing of output directories, I was hacking around with Qinusty@381923e#diff-48b3c6a7d58dce08bdf7f742b515e206R453 as a potential solution of concatting the paths of the working directory with output directories to avoid having to handle .. file path components within bb-storage library methods.

[tmewett]

(The above issue but as a comment here)

I've encountered this bug when using Buildbarn as a RE service for recc.

For example, when using CMake, or any build system doing out-of-tree builds, it is typical to have a directory structure such as

project-root (input root)
+- sources
`- my.build (working directory)
   +- objects
   `- Makefile

The build is started by running Make in project-root/my.build, compiling the inputs in ../sources into objects.

However, due to the described bug, Buildbarn will attempt to create the output object files in project-root/objects instead of project-root/my.build/objects. This causes a server-side error, in my case along the lines of: Assembler messages: Fatal error: can't create objects/source_1.c.o: No such file or directory.