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 
considered this commit as preparations to actively use introduced 
dependency.