[Bug] `tar` rule doesn't embed runfiles when `--build_runfile_manifests=false`

[cerisier]

When using the tar rule along with --build_runfiles_manifests=false, runfiles are not added to the archive.
I believe this is due to the way the tar rule expects the existence of the MANIFEST to deduce the runfiles directory.

bazel-lib/lib/private/tar.bzl

Lines 227 to 230 in 408f76c

	if not default_info.files_to_run.runfiles_manifest:
	continue
	runfiles_dir = _calculate_runfiles_dir(default_info)

and

bazel-lib/lib/private/tar.bzl

Lines 123 to 126 in 408f76c

	if manifest.short_path.endswith("_manifest") or manifest.short_path.endswith("/MANIFEST"):
	# Trim last 9 characters, as that's the length in both cases
	return manifest.short_path[:-9]
	fail("manifest path {} seems malformed".format(manifest.short_path))

The problem is:

• if using --build_runfiles_manifests=false then there is no MANIFEST or .runfiles_manifest to deduce from.
• if using --enable_runfiles=false and --build_runfiles_manifests=false then there are no .runfiles directory at all.

I wonder if there is a reliable way to deduce the presence of runfiles, other than checking on existence of MANIFEST file.
And a way to add the runfiles_dir mtree_line only if we know there will be runfiles.

I wonder if one solution wouldn't be to deduce a runfiles_dir from any src[DefaultInfo].default_info.files_to_run.executable and add an mtree_line for it even in the case where there is no runfiles at all.

This would result in having a .runfiles directory for each executable even in the rare event where there are no runfiles at all.

If that's acceptable, I can submit a PR.

[cerisier]

Maybe @fmeum would know something about that.

[fmeum]

I agree that creating a .runfiles directory for each executable is the correct approach. Runfiles are never empty as they always at least contain the executable itself. The logic that inspects runfiles_manifest can be removed.

Happy to review a PR!