Re: [PATCH v2] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el))

[Max Nikulin <manikulin@gmail.com>]

> +;; 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.