From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id 8PMNMZOYMWT1RAEASxT56A (envelope-from ) for ; Sat, 08 Apr 2023 18:38:43 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id YBU8MJOYMWSqTQAAG6o9tA (envelope-from ) for ; Sat, 08 Apr 2023 18:38:43 +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 5D33A2959D for ; Sat, 8 Apr 2023 18:38:43 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1plBZY-0003Q1-OB; Sat, 08 Apr 2023 12:37:52 -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 1plBZW-0003Po-OL for emacs-orgmode@gnu.org; Sat, 08 Apr 2023 12:37:50 -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 1plBZV-0006Pw-4j for emacs-orgmode@gnu.org; Sat, 08 Apr 2023 12:37:50 -0400 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1plBZS-00076y-Li for emacs-orgmode@gnu.org; Sat, 08 Apr 2023 18:37:46 +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: Sat, 8 Apr 2023 23:37:38 +0700 Message-ID: References: <87sfx7degz.fsf@gmail.com> <87v8ks6rhf.fsf@localhost> <87r0t3gahd.fsf@localhost> <87wn2ujk27.fsf@localhost> <87jzymk3dq.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.9.0 Content-Language: en-US In-Reply-To: <87jzymk3dq.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: 27 X-Spam_score: 2.7 X-Spam_bar: ++ X-Spam_report: (2.7 / 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=-0.113, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 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-Seal: i=1; s=key1; d=yhetil.org; t=1680971923; a=rsa-sha256; cv=none; b=nOzJlZ92rmXwuffw5i0VrGRaVSIPJfU51tr/ZTjLgjgdzkiDd/m52bTpYyEz9apZha9s4i aIBB8yl3SiuyDrfCZT9mgkORMYIdZJ0FdDR2Dhto1lykppnWYUkVUhEMe2+PiltNfkHADj VNDhaIy6r9FMfDuteWhgwGs3GsbnFlNEScKbk1jTahooeaL1SaEiEjdiNRRPP21k+yX7/o oSotwDRyERmWAsY04d6LWBxOo9wz1fr8nqt3GDgktaocaLU2eCEc4gdwcuDSk9C2mEErgA xr4+Er7oWFu9k/0Tm3k5P6wNIk66T7I1O+QEolmNd/3xe7jHOvJKanDNSe02Og== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1680971923; 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=4cnVvg79j0IRGw/ym98paqRDSuMTCNdivoouJ/hL1FI=; b=ZPPLvhpb6YSC1rqxJRwEiMkYp2YhvPEiQXb7WZMg2Qxrq5zeh+RvHv/vZ6IFQetQgCSdg0 Pdr2rDpnJug7D4b2vaj3tuVucttozDVIzBMzgAAZSdkcAv9Jh+2hKHDDzQMcN65H8oVfkz vgLcppeuROdlVr+Wnc/24CYbs6MfeMrLwWJB9hKpX1x9WWdEOVv9NX3i8mzUBuj0zBLxBF RXiV9JucHOf3Mdx8kwfW7XlelhPNWgkKeTuYsd31TF+5XCAdyruITsRWHP71I2v4uQZU2M 4zyDRlEjUpiEkBSzvKSJDJhTShMr9BshxL/5ENWRCkBwsJKMvHeKrNeoTX09GA== Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=gmail.com (policy=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" X-Migadu-Scanner: scn0.migadu.com X-Migadu-Spam-Score: -3.22 X-Spam-Score: -3.22 X-Migadu-Queue-Id: 5D33A2959D X-TUID: 6qA6rF9SnWEc > +;; 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.