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.devel Subject: Re: Native-compilation build process (was Re: Loading tramp for dump goes into infinite regress) Date: Wed, 03 Aug 2022 19:15:26 +0300 Message-ID: <831qtx5mn5.fsf@gnu.org> References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> <83fsid5xg6.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13182"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, michael.albinus@gmx.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 03 18:16:21 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oJH2i-0003IE-P7 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 18:16:20 +0200 Original-Received: from localhost ([::1]:38668 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJH2h-0005HW-PH for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 12:16:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38518) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJH1w-0004UB-Nz for emacs-devel@gnu.org; Wed, 03 Aug 2022 12:15:33 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49414) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJH1w-00073G-30; Wed, 03 Aug 2022 12:15:32 -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=M3PgpUfGSIOyTOyrPW9XE5bNHZibk0J/x0A3drqHol0=; b=Bw48qrosXPVQ W5dFw0J1Yro1lkMXNrcS/b/DoG3pWtvZkh9u8bP4yxIJ3VmCauPkjrb5bo/wO7OVde4o+XgN8HhKU MeFYWraBfI2W+1DIL1DvB8u7XelqSdWWU81ILEo+9YMVwqomguf4wad7WywbGPy8RYVoPg9QndZ/3 EIwD8GSBxluFn7j8bLPvl73TqVU2/sSlYNAYHieq1WJDoVTgvqVHUeBBHXfTHc5E3o6Pi+iitqOrW L7KMRQVmUTWIOFxvOEmJC+hD6xMIMtPALkP5wHTlKGWbkBZEVFdg8BkT8QLa2lauBaF6dX6wvR9ck gc1SEsvzAs/IPJ+0+sv7Cg==; Original-Received: from [87.69.77.57] (port=3715 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 1oJH1v-0000uQ-Hv; Wed, 03 Aug 2022 12:15:31 -0400 In-Reply-To: (message from Lynn Winebarger on Wed, 3 Aug 2022 10:53:12 -0400) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293026 Archived-At: > From: Lynn Winebarger > Date: Wed, 3 Aug 2022 10:53:12 -0400 > Cc: Andrea Corallo , Michael Albinus , > emacs-devel , Stefan Monnier > > > Why are you running "make" only in 'src'? Some necessary parts of the > > build must also run "make" in 'lisp' and in other places. > > I'm replicating the 3 stage build process Stefan Monnier (added to the > cc list) described by invoking a shell script from site-load, when > dump-mode is set to pdump. Well, Stefan definitely didn't mean for you to shoot yourself in the foot. Isn't it possible to run these 2 stages from the top-level Makefile? Alternatively, say "make BINDESTDIR=..." etc. Or, as I suggested, copy the default values of these two variables from the top-level Makefile.in to src/Makefile.in. Then it should probably work from 'src' as well, provided that the other variables these two reference are also defined there. > The shell script produces the second stage > build - the one with a dump containing just the files loaded directly > from loadup - then uses it to compile the files loaded by site-load. > It explicitly builds the emacs.pdmp target in src, moves emacs and > emacs.pdmp to emacs-1 and emacs-1.pdmp, then invokes: > make -C ../lisp EMACS=../src/emacs-1 compile-target > TARGETS="${SL_TARGETS}" BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq > comp-file-preloaded-p t)'" > where SL_TARGETS has been extracted from site-load.el using the same > procedure used in constructing lisp.mk You could add BIN_DESTDIR= and ELN_DESTDIR= settings to those commands. > > The final installation _must_ be specified, yes. Using the build > > directory won't help because Emacs already does that internally. IOW, > > it only needs help in knowing where the stuff _will_ be installed > > That is true for the dump that is going to be installed, yes, but for > intermediate stages in the build that knowledge is not required for > the resulting dump to be useful. The Emacs build always produces binaries that can be invoked either way. So if you use our Makefiles, you need to play by their rules. > In any case, once loadup determines there are native compile units > loaded while preparing for the dump, either they all should have the > names fixed up, or an error should be signaled. The names cannot be fixed up, because the build doesn't know how. These two variables get their values from the configure script, where the user specifies where the package will be installed. Without that, the build cannot know their values. > It's not clear to me, though, why the pdmp loading process should > refuse to work if the compilation units recorded in the dump file are > just strings. Because it needs to record in the binary where to look for those *.eln files. Emacs can be installed in a variety of ways, using all kinds of "tricks" like symlinks and such, so the names need to include directories to allow Emacs to find these files quickly at startup. If startup is delayed because Emacs looks hight and low for its files, users will be annoyed. > It seems to me the "dual location" is more of a "nice > to have" feature than a real requirement. No, it's a requirement. If nothing else, the just-built Emacs binary is run as part of the build, so it needs to be able to do that. > There could be a flag to > dump an image with only the (relative) final installation paths > recorded, or it could just be a build that will always be run in place > (e.g. an ordinary user build). Many users never install Emacs, or at least never install some of its versions. Anyway, this is a non-starter: we won't give up this useful functionality. > For user dumps, recording the absolute paths would presumably work > fine, no? No, because then you cannot relocate the Emacs tree to a different top-level directory, and have it still work. There are good reasons behind all these features, they aren't arbitrary nor redundant.