Max Nikulin writes:
> I do not like lengthy emacs commands and make functions to generate
> them. I think, it is better to move such code to a script. A proof of
> concept is attached, however it is rather rough draft
>
> ./epm.el -Q --epm-dir $(emacs_pkgdir)/emacs-%e install compat
> ./epm.el -Q -L ~/src/compat install compat
Good idea. Although, we should not overdo this package management thing.
If we really need complex functionality here, we should better just use
cask/eldev instead of re-inventing the wheel.
Are you willing to improve the draft to be ready for upstream?
I will provide some inline comments below.
> By the way, accordingly to (info "(make) Command Variables") or (info
> "(standards) Command Variables") "Variables for Specifying Commands"
> https://www.gnu.org/prep/standards/html_node/Command-Variables.html
>
> it should be EMACSFLAGS rather than EFLAGS.
Fair point. I now rearranged the commits as you asked and incorporated
this change. See the attached.
Note that also I changed the way compat.el is loaded, making Org throw
an error for older Emacs versions. This will produce more useful error
if someone attempts to load Org as is, without installing compat.el in
older Emacs.
>> I have no problem with this approach when using system packages.
>> However, it is almost guaranteed that compat.el is absent in global
>> load-path as long as compat.el is not built-in.
>
> I see that installation attempt is not performed when packages are
> available. However form my point of view it is normal when compilation
> fails when dependency are not provided. It works so for decades for
> applications that use make. To be precise, usually I expect detection of
> missed libraries from configure scrips, but in some cases they are
> missed. Maybe such experience was formed when access to network was limited.
>
> For me it is quite natural that make does try to pull dependencies (at
> least by default) and it is my responsibility to ensure availability of
> necessary libraries.
I think that we need to zoom out a bit and discuss the contexts where
Org build system is used:
1. During Org development, by developers who know what they are doing
2. By ordinary users, not necessarily familiar with GNU make and all the
associated build process conventions.
Org developers may need to use the whole spectrum of make targets, and
will generally benefit from isolation of Org from the main Emacs
configuration folder. For example, my `package-user-dir' contains a
number of forks with additional patches applied - it is not the
environment I want to develop (and test) Org in.
Org users will likely use make autoloads, make, make docs, and make
repro. Here, it will make sense to re-use default .emacs.d and package
directory when running make, as ordinary users running make are most
likely aiming to build Org for their own usage. However, make repro and
optionally make docs should avoid re-using user packages as it may cause
inconsistent results if the `package-user-dir' is messed up.
One way to handle the above scenarios might be your idea with AUTODEP.
By default, it will be "auto":
- make compile, docs :: Re-use default `package-user-dir'
- make repro:: Auto-download and ignore `package-user-dir'
- other targets :: Prompt the user
Alternatives will be meant to be used as
AUTODEP=download/user/no make target.
triggering unconditional downloading, using `package-user-dir', and not
using any guess, correspondingly.
WDYT?
>>> I do not like that versions of dependencies are ignored. I have noticed
>>> `package-install-from-buffer'. Perhaps it can be used to generate a stub
>>> package (e.g. org-build-deps) with Package-Requires line obtained from
>>> org.el. The only purpose of this package is to pull dependencies. It is
>>> just an idea, I have not tried such approach.
>>
>> This sounds fragile. I see no reason to go this far and using so complex
>> approach.
>
> My idea is to ensure that *required* version is installed, not some
> stale one. I have not tried such approach though.
I think that it is stretching a bit beyond the complexity we should
allow within Org build system. In your scenario, I can simply do
make cleanpkg and re-download the latest dependencies.
Again, package management is not something we want to overdo. If
really necessary, we will use cask or other proper Elisp development
tool.
> #!/bin/sh
> ":"; # -*- mode: emacs-lisp; lexical-binding: t; -*-
> ":"; exec emacs --script "$0" "$@"
Let's not lock to bash. AFAIK, our makefiles can currently work on
Windows. Using /bin/sh will lead to regression.
So, a simple --batch script for Emacs will be better here.
> (defun epm-init ()
> (unless (epm-nonempty-p epm-dir)
> (setq epm-dir (getenv "EPMDIR")))
> (when (epm-nonempty-p epm-dir)
> (let* ((fmt-expanded (format-spec epm-dir `((?e . ,emacs-version
> (dir (directory-file-name (expand-file-name fmt-expanded
> ;;
