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

[Max Nikulin]

Ihor,

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

or

export EPMDIR="$HOME/.cache/epm/emacs-%e"
./epm.el install compat

to just abort compilation due to absent dependency

./epm.el missing compat

On 20/04/2023 16:27, Ihor Radchenko wrote:

Max Nikulin writes:


Sure. And you will have such option (EFLAGS).


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.


In my opinion, ideally there should be 3 options for dependency management:
1. Completely disabled. If load from default paths failed than it is a
fatal error.


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.



2. Use specified directory outside of Org tree (~/.emacs.d/elpa by
default) or any other directory that you named pkgdir. Only dedicated
target may clean this directory.


This is mostly an equivalent of -L switch.


No, -L is for source directories of package (e.g. git repositories). I 
mean namely alternative `package-user-dir', but not managed by make.



I do not like the idea of
using ~/.emacs.d/elpa default. It is fragile if this default ever
changes.


I still consider it as a reasonable default for a user having just one 
emacs version who is going to build and run org. Both steps may use the 
same package directory. A developer who switches between various emacs 
versions may have set of packages for each emacs version.



3. Install packages to Org source/build directory.

You decided to make 3 the default variant. I believe, it should be
activated by a variable, e.g. AUTODEP = 1 in local.mk or from command
line "make compile AUTODEP=1


It is now activated by EPACKAGES being non-empty.


And it is non-empty by default because it defines list of build 
dependencies, not whether they should be managed by make.



I think, it is better to require an additional command

make autoloads
make fetch-dependencies
make compile


Maybe. Then, also make doc and make install?


In general "make install" may be executed by root while "make all" is a 
task for regular user. "make doc" is an optional step, so I do not see 
any problem. Ideally it might be


make fetch-dependencies # or specify package directory
# or load path in local.mk
make all

followed by optional doc or install


And make repro,


I have not justified my point of view to make repro yet.


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.



Subject: [PATCH 3/7] Use compat.el library instead of ad-hoc compatibility
  function set

* mk/default.mk (EPACKAGES): Demand compat library during compile time.


when I asked for more granular commits I expected this change in


Subject: [PATCH 2/7] org-compat: Enable compat.el


To separate adding dependency and replacing org-compat functions to compat.


For me, PATCH 3/7 grouping is more reasonable. So, I disagree.
Splitting EPACKAGES modification would create transient commit with
non-working Org.


I just do not like that a single line change in default.mk (modification 
of build process) is buried in a large patch (changes of the code). My 
idea was that



-EPACKAGES ?=
+EPACKAGES ?= compat


should be in the same commit as


-;; Package-Requires: ((emacs "26.1"))
+;; Package-Requires: ((emacs "26.1") (compat "29.1.4.1"))


Currently patch 2 requires compat, but it is provided till patch 3. 
Despite in commit 2 the package does not do anything useful, I 

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

[Ihor Radchenko]

Max Nikulin  writes:

>> Sure. And you will have such option (EFLAGS).
>> However, I decided to enable auto-downloading by default to not break
>> the previous working compilation instructions.
>
> For me adding external dependencies is strong enough reason to change 
> compiling instructions. My vote is for clear separation of dependency 
> management (even if performed through make targets) and 
> compiling/testing/etc.
> ...
> In my opinion, ideally there should be 3 options for dependency management:
> 1. Completely disabled. If load from default paths failed than it is a 
> fatal error.

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.

> 2. Use specified directory outside of Org tree (~/.emacs.d/elpa by 
> default) or any other directory that you named pkgdir. Only dedicated 
> target may clean this directory.

This is mostly an equivalent of -L switch. I do not like the idea of
using ~/.emacs.d/elpa default. It is fragile if this default ever
changes.

> 3. Install packages to Org source/build directory.
>
> You decided to make 3 the default variant. I believe, it should be 
> activated by a variable, e.g. AUTODEP = 1 in local.mk or from command 
> line "make compile AUTODEP=1

It is now activated by EPACKAGES being non-empty.

> I think, it is better to require an additional command
>
> make autoloads
> make fetch-dependencies
> make compile

Maybe. Then, also make doc and make install?
And make repro, which is dislike in particular - make repro is supposed
to be easy to use for users unfamiliar with Emacs internals or typical
GNU make conventions.

>> +package-install = --eval '(unless (require '"'"'$(package) nil t) (message 
>> "%s" load-path) (package-install '"'"'$(package)))'
>
> 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.

>> +EMACS_VERSION := $(shell $(EMACS) -Q --batch --eval '(message "%s" 
>> emacs-version)' 2>&1)
>
> Ideally $(BATCH) should be used, but it is defined below. (princ 
> emacs-version) is an alternative, but I have not idea which variant is 
> better.

I used $(EMACS) on purpose. $(BATCH) may contain more things, which we
do not want (on purpose) here.

>> Subject: [PATCH 3/7] Use compat.el library instead of ad-hoc compatibility
>>  function set
>> 
>> * mk/default.mk (EPACKAGES): Demand compat library during compile time.
>
> when I asked for more granular commits I expected this change in
>
>> Subject: [PATCH 2/7] org-compat: Enable compat.el
>
> To separate adding dependency and replacing org-compat functions to compat.

For me, PATCH 3/7 grouping is more reasonable. So, I disagree.
Splitting EPACKAGES modification would create transient commit with
non-working Org.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Max Nikulin]

On 13/04/2023 19:42, Ihor Radchenko wrote:

Max Nikulin writes:
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.


Sure. And you will have such option (EFLAGS).
However, I decided to enable auto-downloading by default to not break
the previous working compilation instructions.


For me adding external dependencies is strong enough reason to change 
compiling instructions. My vote is for clear separation of dependency 
management (even if performed through make targets) and 
compiling/testing/etc.


Last years I rarely use make directly to build software besides the 
cases when I am involved in development. I strongly prefer .deb 
packages. Earlier it was usual practice that "make" or "make all" failed 
if dependencies were not provided. Actually often it was configure that 
reported unavailable libraries. So network requests may be more 
surprising for users than failures due to missed dependencies. It is OK 
for e.g. gradle, but not for make to fetch packages. I expect that 
maintainers of packages from Linux distributions would prefer to avoid 
mixing of compiling and loading dependencies as well.


In my opinion, ideally there should be 3 options for dependency management:
1. Completely disabled. If load from default paths failed than it is a 
fatal error.
2. Use specified directory outside of Org tree (~/.emacs.d/elpa by 
default) or any other directory that you named pkgdir. Only dedicated 
target may clean this directory.

3. Install packages to Org source/build directory.

You decided to make 3 the default variant. I believe, it should be 
activated by a variable, e.g. AUTODEP = 1 in local.mk or from command 
line "make compile AUTODEP=1


I think, it is better to require an additional command

make autoloads
make fetch-dependencies
make compile


+package-install = --eval '(unless (require '"'"'$(package) nil t) (message "%s" 
load-path) (package-install '"'"'$(package)))'


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.



$(FIND) $(pkgdir) -name \*.elc -delete


Looks fine, except that now we have part of the targets using $RM
variable and part of the targets ignoring it. I am not sure if it is a
problem. I am slightly in favour of keeping the existing approach with
$RM.


I have realized that -delete action is not a part of POSIX 
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html
Anyway you removed this line and I like it since I suspected some issues 
when "make compile" is invoked twice.



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.


No, AFAIK:


It is sour. Another deficiency of Emacs package management is that 
errors during compiling of dependencies do not cause immediate failure 
of make.



+EMACS_VERSION := $(shell $(EMACS) -Q --batch --eval '(message "%s" emacs-version)' 
2>&1)


Ideally $(BATCH) should be used, but it is defined below. (princ 
emacs-version) is an alternative, but I have not idea which variant is 
better.



-;; Package-Requires: ((emacs "26.1") (compat "29.1.4.1"))
+;; Package-Requires: ((emacs "26.1") (compat "29.1.3.2"))


thanks


Subject: [PATCH 3/7] Use compat.el library instead of ad-hoc compatibility
 function set

* mk/default.mk (EPACKAGES): Demand compat library during compile time.


when I asked for more granular commits I expected this change in


Subject: [PATCH 2/7] org-compat: Enable compat.el


To separate adding dependency and replacing org-compat functions to compat.

Earlier I used the following procedure: git rebase -i, mark some commit 
for edit, git gui, unstage lines from commit, create new commit, reorder 
and squash/fixup commits on next iteration of rebase -i. Perhaps magit 
can do the same tricks as "git gui". If all changes of some file should 
be moved to another commit it should be easier to use git checkout 
COMMIT FILE.

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

[Ihor Radchenko]

Max Nikulin  writes:

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

No, AFAIK:

D.8 Conventional Headers for Emacs Libraries

‘Package-Requires’
 If this exists, it names packages on which the current package
 depends for proper operation.  *Note Packaging Basics::.  This is
 used by the package manager both at download time (to ensure that a
 complete set of packages is downloaded) and at activation time (to
 ensure that a package is only activated if all its dependencies
 have been).

 Its format is a list of lists on a single line.  The ‘car’ of each
 sub-list is the name of a package, as a symbol.  The ‘cadr’ of each
 sub-list is the minimum acceptable version number, as a string that
 can be parsed by ‘version-to-list’.  An entry that lacks a version
 (i.e., an entry which is just a symbol, or a sub-list of one
 element) is equivalent to entry with version "0".  For instance:

  ;; Package-Requires: ((gnus "1.0") (bubbles "2.7.2") cl-lib (seq))

 The package code automatically defines a package named ‘emacs’ with
 the version number of the currently running Emacs.  This can be
 used to require a minimal version of Emacs for a package.

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

We can put older version require now, indeed. However, later we should
not constrain ourselves about bumping compat version as necessary.

Considering Debian lifecycle, it is pretty much guaranteed that we will
require the compat version that is not installed by Debian, eventually.

In any case, see the attached additional patch.

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

Sure. And you will have such option (EFLAGS).
However, I decided to enable auto-downloading by default to not break
the previous working compilation instructions.

It may, however, be worth documenting EFLAGS in WORG. See the attached
patch.

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

May you elaborate what you mean by "more manual"? What concrete change
in the patch do you have in mind?

> Untested:
>
> $(FIND) $(pkgdir) -name \*.elc -delete
>
> "@" for silencing is intentionally dropped, parenthesis are unnecessary 
> for single condition.

Looks fine, except that now we have part of the targets using $RM
variable and part of the targets ignoring it. I am not sure if it is a
problem. I am slightly in favour of keeping the existing approach with
$RM.

>>> 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 :=

That's what I did in one of the patches (use :=).

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

Agree. Will do.
See the attached.

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

Done.

>From c5ba5773e69d16930fc12db6fbe0d907fae926cd Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sat, 8 Apr 2023 19:05:37 +0200
Subject: [PATCH 1/4] mk/default.mk (pkgdir): Make it more clear that we indent
 to use top git dir

* mk/default.mk (top_builddir): New variable storing top-level directory.
(pkgdir): Use the new variable.
---
 mk/default.mk | 3 ++-
 1 file changed, 

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

[Max Nikulin]

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

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

[Ihor Radchenko]

Max Nikulin  writes:

>> I know no other Emacs packages that manage dependencies using make.
>
> org-ql uses a helper shell script. org-roam and projectile use eldev 
> that is procedural, not declarative build system. I have not figured out 
> which way magit handles dependencies. I have no more ideas what projects 
> may involve unit tests and dependencies.

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.

Also, eldev is not on ELPA, and we cannot use it at all.

As for makem.sh, AFAIK, it will be even worse wrt network access - it
tries refreshing and downloading some packages by default, unless we
explicitly disable that feature. And under the hood, makem.sh anyway
does the same emacs --eval thing I used in the patch.

>>> 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".

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

> By the way, it is 
> better to explicitly express that path is relative to top project 
> directory by defining e.g. top_builddir (or abs_top_builddir) at first and
>
> pkgdir = $(top_builddir)/pkg-deps

How to define top_builddir? If also via `pwd`, I see not much difference.

> Today I noticed the following trick in (likely stale) 
> https://github.com/org-roam/org-roam/blob/main/default.mk
>
> TOP := $(dir $(lastword $(MAKEFILE_LIST)))
>
> I have not realized if it is safe enough.

Reading through 6.14 Other Special Variables section of make manual, it
does not look safe - MAKEFILE_LIST may be altered by presence of includes.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

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

[Max Nikulin]

On 03/04/2023 00:00, Ihor Radchenko wrote:

Max Nikulin writes:


Ihor, do added makefile rules follow best practices used by other Emacs
packages in respect to dependencies?

I know no other Emacs packages that manage dependencies using make.


org-ql uses a helper shell script. org-roam and projectile use eldev 
that is procedural, not declarative build system. I have not figured out 
which way magit handles dependencies. I have no more ideas what projects 
may involve unit tests and dependencies.


Actually Org uses make just as interface, not as a declarative build 
system that is able to minimize work by updating only necessary targets. 
Build rules are effectively procedural: complete rebuild on every 
invocation.



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



+pkgdir = $(shell pwd)/pkg-deps


Make has CURDIR variable, but I am unsure if it is safe to use it in 
this context.


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. By the way, it is 
better to explicitly express that path is relative to top project 
directory by defining e.g. top_builddir (or abs_top_builddir) at first and


pkgdir = $(top_builddir)/pkg-deps

Today I noticed the following trick in (likely stale) 
https://github.com/org-roam/org-roam/blob/main/default.mk


TOP := $(dir $(lastword $(MAKEFILE_LIST)))

I have not realized if it is safe enough.

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

[Ihor Radchenko]

I am attaching a slightly tweaked version of the patch that will make
less use of internet connection (use only when really, really
necessary), fixes variable expansion to be done once instead of in every
make sub-process, and adds some extra info messages.

Max Nikulin  writes:

> Ihor, do added makefile rules follow best practices used by other Emacs 
> packages in respect to dependencies?

I know no other Emacs packages that manage dependencies using make.

> I do not like the idea of network queries on every make.

Any better suggestions?

> In some cases I would prefer to specify a directory where compat.el is
> installed, so Makefile should not try to manage this directory.

Sure. See EFLAGS variable. Makefile will not try to manage
-L /path/to/compat directory.

> Originally I expected that either compat.el would be included into Org 
> repository either as a copy of the file or as git submodule.

That will create maintenance nightmare.

> In addition I am afraid of recursive removal of directories. It is too 
> easy to remove too much.
>
>> +pkgdir = $(shell pwd)/pkg-deps
>
> Make has CURDIR variable, but I am unsure if it is safe to use it in 
> this context.

Actually, we need pkgdir := $(shell pwd)/pkg-deps.
CURDIR is wrong because default.mk will trigger evaluation in every make
sub-process as well.

>> +-$(FIND) $(pkgdir) \(  -name \*.elc \) -exec $(RM) {} +
>
> find has -delete action. I see that "-exec $(RM)" is already used.

I just copied the existing code.
I guess we can use -delete as well. I do not have a lot of experience
with this usage of find. May you share the equivalent find call with
-delete that works with this patch?

>> +cleanpkg:
>> +-$(RMR) $(pkgdir)
>
> Perhaps it is impossible to completely avoid recursive deleting of 
> directories, but I still afraid of cases like
> https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/issues/123
> https://news.ycombinator.com/item?id=9254876

I do not think that we have any significant risk here.
I would not mind alternative way to implement clean target though. If
you know one.

>> Subject: [PATCH 2/3] Use compat.el library instead of ad-hoc compatibility
>>  function set
>
> It would be easier to review if this patch was split into 2 parts:
> - add compat.el dependency (unused)
> - replace functions to ones from compat.el

Sure, but after spending half an hour trying to decouple this part, I
gave up and decided to leave it as is. And there is nothing fancy in
adding compat dependency in 2/3 patch anyway. Just one (require 'compat
nil t), two macro definitions adviced by compat manual (copy-paste from
compat code), and adding compat to EPACKAGES in makefiles.

>From f95433f53878e8371bb28a045fdb5d06cf0877b9 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Sat, 1 Apr 2023 12:00:48 +0200
Subject: [PATCH 1/6] Upgrade Org build system to handle third-party
 dependencies

* mk/default.mk (pkgdir): New variable holding the location of
third-party packages to be downloaded if necessary during compilation.
(EFLAGS): New variable holding extra flags to be passed to Emacs
executable when running make.
(EPACKAGES): List of packages to be installed (unless already present
in the `load-path') during compilation.
(package-install):
(INSTALL_PACKAGES): New command to download and install missing packages.
(BATCH): Update, setting default package location to pkgdir.
* mk/targets.mk (uppkg): New target to download install missing
packages.
(check test):
(compile compile-dirty): Use the new uppkg target.
(cleanpkg): New target cleaning up the downloaded packages.
(cleanall): Use the new target.
(.PHONY):
(CONF_BASE):
(CONF_DEST):
(CONF_CALL): Update according to the new variables and targets.
* .gitignore: Ignore the downloaded packages.

This commit paves the way towards third-party built-time dependencies
for Org.  In particular, towards including compat.el dependency.

According to EPACKAGES, we can auto-download necessary packages,
unless they are manually specified via -L switches in EFLAGS.

Link: https://orgmode.org/list/87v8ks6rhf.fsf@localhost
---
 .gitignore|  1 +
 mk/default.mk | 24 +++-
 mk/targets.mk | 24 
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/.gitignore b/.gitignore
index 4bb81c359..a58670c90 100644
--- a/.gitignore
+++ b/.gitignore
@@ -71,6 +71,7 @@ t
 auto
 tmp
 TODO
+/pkg-deps
 
 # and collateral damage from Emacs
 
diff --git a/mk/default.mk b/mk/default.mk
index fa46661e8..997b22b66 100644
--- a/mk/default.mk
+++ b/mk/default.mk
@@ -31,6 +31,15 @@ GIT_BRANCH =
 TMPDIR ?= /tmp
 testdir = $(TMPDIR)/tmp-orgtest
 
+# Where to store Org dependencies
+pkgdir = $(shell pwd)/pkg-deps
+
+# Extra flags to be passed to Emacs
+EFLAGS ?=
+
+# Third-party packages to install when running make
+EPACKAGES ?=
+
 # Configuration for testing
 # Verbose ERT summary by default for Emacs-28 and above.
 # To override:
@@ -72,12 +81,22 @@ REPRO_ARGS ?=