From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62762: Incremental builds and Lisp files dependencies pulling a new version of the code Date: Sat, 06 May 2023 10:51:41 +0300 Message-ID: <83h6sphp82.fsf@gnu.org> References: <17b74a48-94e1-9106-cc79-d31972313910@gutov.dev> <837cujaqzq.fsf@gnu.org> <87wn2ilwed.fsf@localhost> <83zg7ealrd.fsf@gnu.org> <87pm8a8dx4.fsf@localhost> <87pm7vt0mx.fsf@localhost> <87cz3k8i27.fsf@localhost> <87sfcfdldt.fsf@localhost> <87bkj1g10g.fsf@localhost> <1c5d0ff0-5bae-1123-d2f7-64d9013fbc0f@gmail.com> <6070e598-7dee-1b7a-7f97-26a90618cb7a@gmail.com> <1f236996-5f17-3be8-d01c-803e065985f7@gmail.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14362"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, 62762@debbugs.gnu.org, bzg@gnu.org, dmitry@gutov.dev, monnier@iro.umontreal.ca, acm@muc.de To: Max Nikulin Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 06 09:51:14 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pvChG-0003SO-7R for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 May 2023 09:51:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pvCh7-0004CG-Aj; Sat, 06 May 2023 03:51:05 -0400 Original-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 1pvCh4-0004C5-N8 for bug-gnu-emacs@gnu.org; Sat, 06 May 2023 03:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pvCh4-0002Q1-F2 for bug-gnu-emacs@gnu.org; Sat, 06 May 2023 03:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pvCh4-0004V8-9f for bug-gnu-emacs@gnu.org; Sat, 06 May 2023 03:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 May 2023 07:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62762 X-GNU-PR-Package: emacs Original-Received: via spool by 62762-submit@debbugs.gnu.org id=B62762.168335945917284 (code B ref 62762); Sat, 06 May 2023 07:51:02 +0000 Original-Received: (at 62762) by debbugs.gnu.org; 6 May 2023 07:50:59 +0000 Original-Received: from localhost ([127.0.0.1]:58685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvCh0-0004Ud-Qj for submit@debbugs.gnu.org; Sat, 06 May 2023 03:50:59 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37812) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pvCgy-0004Th-6s for 62762@debbugs.gnu.org; Sat, 06 May 2023 03:50:56 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvCgq-0002Ow-MP; Sat, 06 May 2023 03:50:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=dP+1+GsLXQu9Q7Z0mTFQb/tYKTb36eAYm/dHlkFk9R4=; b=h3ZrOfivfjdQ DsWcO+DLFYOSXLuut4huPmH8NIaxURuXJLM2wnDgSoFAeCoHHliTcYHfiOl7EuMC3Q4dQigzNCPwu pvewcDLnfwUFsA6A94saXAYV7ItWNmRU8nwmhjteoIFv0B3UA4PsbwFXJOzBMooJQX9viM7/XlNMG BAY6+Mb/xEx8TCdZ3Tjf0Ft6MkkjO7LAeMUVNuuOfviW4rWFQQsV78PM85LQa4EeVwKDxWNl4YqcN wdsqBb5vI5aju6waAKYvh09E80w/fA/Qd+PnJD+JDXifVX6odIFztJmOci/TU8HsyJOHRFfrkC0/o FqJ8yZTET9z9k81dYCrfNA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pvCgq-0006M1-3B; Sat, 06 May 2023 03:50:48 -0400 In-Reply-To: <1f236996-5f17-3be8-d01c-803e065985f7@gmail.com> (message from Max Nikulin on Sat, 6 May 2023 13:00:38 +0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:261163 Archived-At: > Date: Sat, 6 May 2023 13:00:38 +0700 > Cc: Ihor Radchenko , Eli Zaretskii , > bzg@gnu.org, dmitry@gutov.dev, 62762@debbugs.gnu.org, > Alan Mackenzie > From: Max Nikulin > > On 06/05/2023 01:17, Stefan Monnier wrote: > > I'll refrain from discussing this here. Incremental recompilation > > problems should be discussed in another bug report, IMO. > > I will try to explain why this bug report was caused by issues with > incremental builds. I've started a new thread, because I agree with Stefan: this is a separate issue. Please reply with this new thread's Subject. > Let's assume that a trouble with cyclic dependencies is a real one (I > have not convinced in that). A way to the correct builds is to > *completely* avoid loading of .elc files during incremental builds. When > only a few files changed then relying purely on .el files should cause > significant performance penalty. Exactly. And please don't forget that quite a few files are preloaded, so using only *.el means to preload only the *.el files, which will result in a significantly slower bootstrap-emacs binary, and the build will become annoyingly slow, for no good reason. > Unfortunately it would not work without > describing at least some dependencies. In the `org-assert-version' they > should be at least that all lisp/org/*.elc files depend on > lisp/org/org-version.el and lisp/org/org-macs.el. Without automatic > dependency generation it is a kludge, but it should significantly > alleviate the issue. This doesn't really work, not as long as we use Make: some *.elc files might not exist yet, for whatever reasons, so Make will try to generate them first, thus disrupting the order of generation that you will try to encode in the dependencies. We already tried that, and it didn't work, not even just for Org. > Commits pushed so far trade false positives to false negatives and to > reports of bugs due to "undefined" functions and incorrect signatures to > Org developers and maintainers. Those commits only affect byte compilation of Org as part of building Emacs, so I see no reason why they should cause the above issues for Orge developers. > Perhaps `org-assert-version' may be improved, but this report was caused > by broken build rules. The bug#62762 was reported because Org behaved unlike any other Lisp package in Emacs. We have other packages that define macros used in many other *.el files, and none of them does the version-check like Org did. The problems with making incompatible changes in one or more of the macros are well known to Emacs developers who rebuild Emacs frequently, and we have ways to deal with them. Some of those ways (the simplest ones) are encoded in the top-level Makefile, see ADVICE-ON-FAILURE there. There are others, more subtle ones, for those, like myself, who don't bootstrap, ever, except the first time a fresh repository is cloned. That Org behaved in a stark different manner was therefore an unpleasant annoyance, so we now fixed that by making Org behave in this regard like any other Lisp package in Emacs -- but only when Emacs is built, because the knob which forces this behavior is off by default, and is only turned on by lisp/Makefile in the Emacs tree.