From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Native-compilation build process (was Re: Loading tramp for dump goes into infinite regress) Date: Wed, 3 Aug 2022 23:33:56 -0400 Message-ID: References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> <83fsid5xg6.fsf@gnu.org> <831qtx5mn5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12185"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, michael.albinus@gmx.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Aug 04 05:35:06 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 1oJRdZ-0002wU-Oc for ged-emacs-devel@m.gmane-mx.org; Thu, 04 Aug 2022 05:35:05 +0200 Original-Received: from localhost ([::1]:42828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJRdY-00084w-Kc for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 23:35:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35492) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJRcl-00077H-9M for emacs-devel@gnu.org; Wed, 03 Aug 2022 23:34:15 -0400 Original-Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]:36596) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oJRci-0003Cp-Fj; Wed, 03 Aug 2022 23:34:14 -0400 Original-Received: by mail-pj1-x1033.google.com with SMTP id 15-20020a17090a098f00b001f305b453feso3995836pjo.1; Wed, 03 Aug 2022 20:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5ZjtbcjYlczU743Zt3+iYM3cyOaWI/K+z4rVKtW2aFs=; b=JIjTn9iDnKOr9bsiRshLcEfbVCoPqj5A//464v0n8FbNDWIxr7T2bKfAs1XEYVfUyp jylddbNp8GlWspcXjJo0BmqLL0mHwqITXvMPFV8P38Svwcn0rgAJ+iruVKW+ZTbr5J0R PR1Qcyt+3YDQVf59TpSfSfoQASElUa0IJ14K41Ol/61l5h1EE5VSTVGFYkI8jrJAjno8 JZQNjn7bqbn7O3fBBwD76ASSpOl/h5YsR6E3Sb3OxFQ4f4g9KuKfTbTbdCT2cmZXUts5 KTXfxD6sYo8B1XXHsvrzcP1umUfCkIgkx2+l0hjb23OfG7GQ5Xv4GuPTJAgjxclxFGfM mtWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5ZjtbcjYlczU743Zt3+iYM3cyOaWI/K+z4rVKtW2aFs=; b=1gGElk0NTP1gaNRhWbiDs/UNV2KG5+uDyO8j0nPB/tAnj9T5bvxVlyBDyvITelgBgi Jt9UFz/nOm0p1yCGd3AiJ3BES8G+rxZlffBbC2+On8VDl6JA62Fw6KsX7maSuMIwerlv U+T3vNx97sya+wkD0bYTUkeVJjTX0R11x1mZFfiMykJ3EpLh3dyrwdU4hJrDd9Imk7Bn pWjpCY9STtLpQcrRr+Hx+1IrKR9fmidU1LiMrcBLirURex0ZNZsqTCMfZP4JrQQq9hb1 Hjp9xbU0Cn8yDiTRIEgA3KiNJn9sd11qjpHv0bICLZVxGtW+AS4jaOuSvxm9VnV/Ohem 48wQ== X-Gm-Message-State: ACgBeo1yDJljAlgCE4dqLTWa1QDAaCcNS0AgR8P22OthKyoAGVQYr8cY u+5sjnNLwfM4T8+5SlYxDrCKR9ozU48+5PXo1ew1IZwMg28= X-Google-Smtp-Source: AA6agR60wmZIv/jv7cIkzaCmvhwRVHbcoOCp+07zXE+jWQ6I9jTqIOABkdB6ttg4dHFOY0efDmHV20YVnembtNhxU60= X-Received: by 2002:a17:90a:e7cb:b0:1f5:38:cb53 with SMTP id kb11-20020a17090ae7cb00b001f50038cb53mr8392799pjb.110.1659584049441; Wed, 03 Aug 2022 20:34:09 -0700 (PDT) In-Reply-To: <831qtx5mn5.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1033.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action 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:293036 Archived-At: On Wed, Aug 3, 2022 at 12:15 PM Eli Zaretskii wrote: > > > 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? Not that I can tell - I don't know what targets I would use from the top level, but I do know that "emacs.pdmp" and "src/emacs.pdmp" produce an "unknown target" response. In any case, I don't believe I have shot myself in the foot. I was just able to produce and use a dump with * 698 libraries in the preloaded-file-list * 136 files listed in lisp.mk * 521 files listed in site-load.mk (the file I generate from site-load) * I'm not sure where the remainder are from * 426 native compilation units in "all-loaded-comp-units-h" * 1126 eln files under native-lisp/28.1-/preloaded - none appear directly in 28.1- * 1504 elc files under lisp * 1557 el files under lisp I'm not sure why some of the files were byte compiled but not native compiled (or at least, not loaded in the dump). But at the end of site-load I loaded cus-start (with dump-mode set to nil), cus-load, and finally cus-edit. The result of running customize is promising in terms of (lack of) lag, but I won't really know if it works until I've added all the additional site-lisp files in the mix. My solution was to allow the dump to contain a string with the absolute path. That works for my purposes. When I have something I want to install permanently, I'll specify the final location as well. Or I might just create a dump only intended to be run from the installed location. I think my total modifications to the distribution source are in the range of maybe 50 lines of C and a handful of changes of "defconst" to "defvar" in the lisp source files. Since one of the goals of this particular exercise is to be able to minimize the local maintenance of patches, I consider it to be a win. Keep in mind I don't control the rest of the build tools on this system, so autoconf etc may change without my input. That's why I rather not do anything that touches the configure script(s) or Makefile.in. I'd rather modify the shell script to accomodate any changes in the process or set of targets post-configure, and rely on the emacs maintainers expert knowledge of the configuration process to deal with any changes in the build toolset. One change I had to make was to set native-comp-deferred-compilation to nil: make -C ../lisp EMACS=../src/emacs-1 compile-target TARGETS="${SL_TARGETS}" BYTE_COMPILE_EXTRA_FLAGS="--eval '(setq comp-file-preloaded-p t native-comp-deferred-compilation nil)'" Otherwise I would end up with hundreds of lingering emacs processes doing something with an argument that was something like "subr-int-native-comp--call-interactively-...". The recursively invoked make process for Stefan's "stage 2" would nominally complete, but the resulting dump would have a random number of native compilation units loaded. Hopefully that's useful information for someone. > > 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. That's your call, I'm just pointing out above that it's usually better to signal an error when it happens (not supplying the arguments you are stating as a requirement) than to signal an error over the subsequent symptoms of the actual error (in this case, the attempt to load the incoherent eln file). I just don't understand why you would ever want emacs to produce a dump file that will never be loadable according to the requirements you are enforcing. Are we actually in disagreement on 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. I don't doubt that, but this point is a little humorous given the evident number of daily users of the latest commit in the master trunk. > > Anyway, this is a non-starter: we won't give up this useful > functionality. I never said anything about giving it up. That's distinct from not making it a hard requirement. I'm just clarifying the point I made. I don't expect your position to change, but I'd prefer the rejection to be of what I actually suggested. Thanks, Lynn