Closed phst closed 1 month ago
@gutron
Is that sufficient to work? When I tried a similar change downstream, it didn't see the additional inputs. First, it's in the root directory of the runfiles, so the relative paths are wrong unless the source file happens to be in the workspace root. But even after adding a (cd (file-name-directory input))
, I wasn't able to get it to see the other file.
The source file ends up in an arg that's referenced in input_args
, wouldn't the other inputs need something analogous?
Did you make further changes in response to my earlier comments? I don't see them. And I'm not sure how you tested this change so far.
I patched the commit locally and tried to use it, but so far it's not working for me. I'm not sure yet what the issue might be, so will investigate more.
It looks like the additional_inputs don't get materialized in the input directory for export-org.el call -- I added debugging code in that file to print the contents of its input directory, and the additional_inputs aren't there. Basically, I replicated what @sfreilich did, and got the same results. My bazel-foo is weak, but I suspect that the additional inputs need to end up as in the data argument to the emacs_binary that is export-org, but I'm not sure how to express that in starlark. Any ideas?
Did you make further changes in response to my earlier comments? I don't see them. And I'm not sure how you tested this change so far.
I tested this locally by first making changes to examples/doc.org, observing some warnings (Org only emits a warning if a setup file isn't found), then making the change to elisp/defs.bzl and observing the warnings to go away.
It looks like the additional_inputs don't get materialized in the input directory for export-org.el call -- I added debugging code in that file to print the contents of its input directory, and the additional_inputs aren't there. Basically, I replicated what @sfreilich did, and got the same results. My bazel-foo is weak, but I suspect that the additional inputs need to end up as in the data argument to the emacs_binary that is export-org, but I'm not sure how to express that in starlark. Any ideas?
This might be due to the additional sandboxing that's possible using a wrapper binary in the toolchain. I've tried to adapt the code for that, could you please check again?
Fixes #570.