Better support for borg-build-shell-command in batch mode
bandali0 opened this issue · comments
I've recently started using @thblt's borg-nix-shell. It provides a borg-nix-shell-build-command function for use with borg-build-shell-command.
I have this excerpt in my init file:
...
(require 'borg)
(borg-initialize)
(require 'borg-nix-shell)
(setq borg-build-shell-command 'borg-nix-shell-build-command)
...And so building packages that use the custom build command works fine in a normal interactive emacs session. The problem arises when trying to run make lib/PACKAGE and generally make on the command line, for building that specific package or batch rebuild all the packages noninteractively.
It seems to be due to the fact that unlike the above excerpt from my init file, naturally borg-build itself doesn't do (require 'borg-nix-shell) (here).
Any thoughts on how to best go about solving this? Perhaps an environment variable that would allow the user insert a string (e.g. the call to require) right after the borg-initialize inside borg-build?
Perhaps an environment variable that would allow the user insert a string (e.g. the call to
require) right after theborg-initializeinsideborg-build?
Sounds reasonable, except I would instead use a variable that users can set in ~/.emacs.d/etc/borg/config.mk. The build target could then explicitly pass that to emacs, possibly using something like --eval "(setq borg-load-libraries '(foo bar))".
That sounds great.
I don't intend to implement that anytime soon though. Maybe you want to try your hands at it?
I'd definitely would like to try my hands at it, if I manage to set aside some time (this semester school work is crazy busy). But feel free to beat me to it if you get a chance :)
I don't know how batch mode works, but borg-nix-shell-build-command is registered as an autoload, as should be any function meant to be used as borg-build-shell-command. This is specified in the manual:
Notice that if the value of this variable is a function, this function must a) be defined in a drone; and b) be registered as an autoload. This is because build happens in a separate Emacs process started with -Q --batch, which only receives the name of the function.
@aminb, if you can't get your initial example to work without (require 'borg-nix-shell), you have an issue somewhere else, probably you need to borg-build borg-nix-shell before anything else. After that, if batch mode calls borg-initialize, everything should work fine there too.
(@tarsius These last few weeks/months have been much more busy for me than I expected, but I still plan to finalize the GPG PR on Magit. Sorry, again, for the various delays, but this is still on my TODO list as high as I can)
@thblt hmm, weird: I definitely did borg-build the borg-nix-shell package, and confirm that the autoloads file was created. But I notice the issue despite that.
More funny behaviour: similar to how I have to borg-build notmuch package in emacs, I have to borg-build org in the terminal, otherwise it doesn't seem to build properly (finishes very quickly).
@thblt @tarsius Is there a way get more verbose output when building a package, so that I could see what's going on?
Is there a way get more verbose output when building a package, so that I could see what's going on?
I don't think so.
Sorry, again, for the various delays,
No problem.
Maybe you guys could look into what's going on here again. This concerns features that I don't need and added anyway despite all good intentions and having very publicly stating that I would not add any features I deem unnecessary or too complicated.
Maybe you guys could look into what's going on here again.
The plural form has got me confused here: is anything expected from me on that issue?
You don't have to do anything of course, but since this concerns a feature that you implemented (I think) it would be nice if you could take another look.
Had a look, and I see how this actually relates to the borg-build-shell-command mechanism I suggested. I assumed the issue had something to do with missing autoloads, but after a quick glance it seems the actual cause is that building packages from the command line doesn't load the Borg config in init.el which sets the borg-build-shell-command (because --batch implies -Q). So we indeed need to move or duplicate this parameter to a different location.
I see two solutions:
- Duplicate the
borg-build-shell-commandvariable as an environment variable in~.emacs.d/etc/borg/config.mk, or generalize it as aBORG_BUILD_INITvariable which would be evaluated as elisp before actually building a package. - Read an optional
/etc/borg/prebuild.elconfiguration file before building any package, whether it is byM-x borg-buildormake lib/$PACKAGE. This would prevent code duplication, since the build configuration would just have to be moved outside ofinit.elto this file (IIUC Borg only builds fromemacs -Q)
None of these is really satisfying, but (2) at least doesn't require any duplication of configuration. What do you think?
@tarsius According to Borg 3's changelog (congratulations!), this:
The new user configuration files ~~/.emacs.d/etc/borg/config.el~ and ~~/.emacs.d/etc/borg/config.mk~ are loaded by borg-build and make if they exist. These files are primarily intended to set the variables borg-emacs-argument (which see) and EMACS_ARGUMENTS. The latter can also be used to set EMACS and/or to define new make targets.
actually implements (2) and solves the current issue, right? Or am I missing something?
I was indeed missing something: with M-x borg-build, ~/.emacs.d/etc/borg/config.el gets loaded only in the parent Emacs process, the one which doesn't actually perform the build. Shouldn't it be loaded in the child instead? The docstring for borg-emacs-arguments suggests setting this variable in both config.mk and config.el, wouldn't it be more natural that the Emacs used for building always load config.el (or a new, distinct build-config.el to avoid breaking changes?) (I may be misunderstanding the use case here though)
Reading my initial response again I realize I should have been more explicit and added "go ahead and try to implement what you need using this existing feature, which was designed for this sort of thing". By the time of my second post I had forgotten I had already implemented that and briefly glimpsing at the previous post apparently wasn't enough to remind me.
Anyway, got to go now. I'll think about when config.el should be loaded when I get back. I do however assume that everything that could be achieved if that file were loaded in both branches of borg-build can already be achieved now. In config.el you can do (setq borg-emacs-arguments '("--eval" "VAR=VAL")) and that has the same effect if you did VAR=VAL in config.mk. At least I think so, gotta run.
5aad7ed should do the trick.