+;; Package-Requires: ((emacs "26.1") (compat "29.1.4.1"))
Is there a way to express (or (compat "29.1.4.1") (emacs "28.1")) to
avoid installing compat in the case of sufficiently new emacs? E.g.
dpkg/apt allows such alternatives.
Early I asked concerning compat-29.1.3. I would prefer to install
elpa-compat system package to avoid network activity in response to
make. Required version matters for those who builds packages for
backport repositories for various linux distributions. It allows to
decide if it is necessary to provide newer elpa-compat or it is enough
to package elpa-org.
On 08/04/2023 18:41, Ihor Radchenko wrote:
I see. Unfortunately, using third-party non-standard packages like
makem.sh or eldev will be more troublesome. We will need to sync Org
repo with them or demand users to install them separately.
I was looking for sources of inspiration. I do not suggest to take these
tools. Perhaps somebody may suggest a better example of build scripts
for Emacs packages.
I do not like the idea of network queries on every make.
Any better suggestions?
Do not run install dependencies for regular targets like test or
compile. At least do not do it unless it is explicitly requested by
command line argument or a variable in local.mk
compat.el is required for "compile" target. Compilation will simply fail
with older Emacs. And "test" triggers "compile".
There are different types of build systems. Some of them allows to
specify which dependencies should be pulled, some do not. My expectation
is that make does not attempt to manage dependencies. For me it is OK to
type an additional command to install them and to fail otherwise.
In my opinion
+ @$(FIND) $(pkgdir) \( -name \*.elc \) -exec $(RM) {} +
command tells that package management capabilities in Emacs are rather
rudimentary (in comparison to e.g. python toolchain). That is why I am
in favor to more manual dependency management. Notice that I am not
against an option to do it from make.
Untested:
$(FIND) $(pkgdir) -name \*.elc -delete
"@" for silencing is intentionally dropped, parenthesis are unnecessary
for single condition.
Actually, we need pkgdir := $(shell pwd)/pkg-deps.
CURDIR is wrong because default.mk will trigger evaluation in every make
sub-process as well.
default.mk is included from top level Makefile only.
Not sure here. I just noticed that GITVERSION got re-calculated many
times when looking at debug output of make. (It was slowing things down
significantly). GITVERSION is in targets.mk though.
GITVERSION is defined as ?=, so it is a variable with deferred
evaluation. Immediately evaluated variable may defined using :=
pkgdir = $(top_builddir)/pkg-deps
How to define top_builddir? If also via `pwd`, I see not much difference.
I consider it as self-documenting code. Intermediate variable makes it
apparent for readers that the directory is relative to the top of the
package file tree.
Since out of source tree builds are not supported, I would consider
adding emacs version to path. The idea is to allow keeping installed
packages when switching between several emacs versions.
A note concerning variable name. For me it is associated for the
directory where current package should be installed. I do not remember
origin, but I noticed that such meaning is used in arch
https://wiki.archlinux.org/title/creating_packages#Defining_PKGBUILD_variables
Perhaps the same name is in gentoo in other sense that makes it suitable
for storage of dependencies.
