From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id OL1JAgOAPWQj5wAASxT56A (envelope-from ) for ; Mon, 17 Apr 2023 19:21:07 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id yP1kAgOAPWQFUAAA9RJhRA (envelope-from ) for ; Mon, 17 Apr 2023 19:21:07 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 9531D38C3D for ; Mon, 17 Apr 2023 19:21:06 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poSWY-0002ot-Ji; Mon, 17 Apr 2023 13:20:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poSWW-0002oI-VX for emacs-orgmode@gnu.org; Mon, 17 Apr 2023 13:20:17 -0400 Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poSWU-00082u-UZ for emacs-orgmode@gnu.org; Mon, 17 Apr 2023 13:20:16 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1poSWS-0006NW-VX for emacs-orgmode@gnu.org; Mon, 17 Apr 2023 19:20:12 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: emacs-orgmode@gnu.org From: Max Nikulin Subject: Re: [PATCH v2] Add compat.el support to Org (was: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)) Date: Tue, 18 Apr 2023 00:20:03 +0700 Message-ID: References: <87sfx7degz.fsf@gmail.com> <87v8ks6rhf.fsf@localhost> <87r0t3gahd.fsf@localhost> <87wn2ujk27.fsf@localhost> <87jzymk3dq.fsf@localhost> <87o7nsdkcw.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US In-Reply-To: <87o7nsdkcw.fsf@localhost> Received-SPF: pass client-ip=116.202.254.214; envelope-from=geo-emacs-orgmode@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: 5 X-Spam_score: 0.5 X-Spam_bar: / X-Spam_report: (0.5 / 5.0 requ) BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.284, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1681752066; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=arA3T4mujjKa4xiPky0pEv8uZ7ZYej2Q1TNdqrYJy6Q=; b=VNq8OQDbGrUTN5QgxmqUnO6Z9LRGyQyZkcZyfdbgsZdhkU+aoNFHBPVV3wziFiZfmFbE6U CE/DqockenSOAghARo11RsREq3Rmdgo3JQyqJfzz9UieBN8O3im2Vo/2O5j4gC3ldMaSsj iwoaETX0A7TFvvU9xsguxDEvgjdmVhML+bDyapnxFQMnoREszRbXI887ysx/Tjha8uCu4d n2mMKjb/3VHeOLEmHtO235yE4x7rvPErEQGmSGUqzs0uxD7erv+2x0CIleSWCO4gxePa18 GJ55KxH5tYw9v7toNlM+lDoYC2BARMaZJDvuPedV95L52LGWCtcYxwDeFxLZsA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) ARC-Seal: i=1; s=key1; d=yhetil.org; t=1681752066; a=rsa-sha256; cv=none; b=uBfWb/uekIQf/FP6AAIU9y/M/zbzWfgHufaPzd6cSozxSV7kUey7x5zvvEeZK1FD7Tf/83 0ouKKVF/wxxJ8DXatnlJZ62EihXmaasIe9vmh2e0UFxJ5wtAQfVSy1The0vF3yo+ER2+8X Z7ovOhr1XSzAAQ71seKENlSj8iBZK+7pUIi79bK6HCqMITGVozQkDNccghF58oAEAzba9v XtTeQPwxq9alij4mZ3lJJ4yiUKwQ19fm/R7FpGXkqH4xUQKWZpPlTY8j8BL7MJ9i4Q5mA/ u2wE41tiIdY28MfzOS9f6fLWVZZRofwGnqUpgHbkYt7p+eZtkZL+jFEoU0ZOtQ== Authentication-Results: aspmx1.migadu.com; dkim=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org"; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=none) X-Migadu-Spam-Score: -2.41 X-Spam-Score: -2.41 X-Migadu-Queue-Id: 9531D38C3D X-Migadu-Scanner: scn1.migadu.com X-TUID: pR8nUAnapnCH 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.