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

[Max Nikulin]

On 01/04/2023 17:31, Ihor Radchenko wrote:
> See the attached patch set adding support of compat.el.

Ihor, do added makefile rules follow best practices used by other Emacs 
packages in respect to dependencies? I do not like the idea of network 
queries on every make. In some cases I would prefer to specify a 
directory where compat.el is installed, so Makefile should not try to 
manage this directory. My impression is that package management code in 
Emacs is too oriented for interactive usage. E.g. python's pip caches 
downloaded packages or allows to specify a proxy or an alternative 
source. Moreover precise version may be specified while only last 
version is hosted on ELPA. In other package managers version lock is 
often preferred to avoid unexpected effects of spurious update. 
Fortunately ELPA packages are at least reviewed before publication.

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

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.

> +       -$(FIND) $(pkgdir) \(  -name \*.elc \) -exec $(RM) {} +

find has -delete action. I see that "-exec $(RM)" is already used.

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

> 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