search

phst / rules_elisp

Bazel rules for Emacs Lisp
Apache License 2.0
11 stars 7 forks source link

elisp_manual: Support additional input files. #571

Closed phst closed 1 month ago

phst commented 2 months ago

Fixes #570.

phst commented 2 months ago

@gutron

sfreilich commented 2 months ago

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?

sfreilich commented 2 months ago

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.

gutron commented 2 months ago

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.

gutron commented 2 months ago

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?

phst commented 2 months ago

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.

phst commented 2 months ago

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?