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: Loading tramp for dump goes into infinite regress Date: Wed, 03 Aug 2022 15:22:01 +0300 Message-ID: <83fsid5xg6.fsf@gnu.org> References: <8735erhrlg.fsf@gmx.de> <83wnc2g0n8.fsf@gnu.org> <83sfmqfxcb.fsf@gnu.org> <83a68yfp6j.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26622"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, michael.albinus@gmx.de, emacs-devel@gnu.org To: Lynn Winebarger Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 03 14:25:24 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 1oJDRC-0006m7-SC for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 14:25:22 +0200 Original-Received: from localhost ([::1]:59044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oJDRB-0001aX-Ky for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Aug 2022 08:25:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33900) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJDO8-0007Ly-Vi for emacs-devel@gnu.org; Wed, 03 Aug 2022 08:22:13 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42132) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oJDO6-0006rO-JJ; Wed, 03 Aug 2022 08:22:11 -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=nb4HrAYxPsgX2D8czmMr/xrD9NezgJLqDHeNx+jtWoQ=; b=UA6ikuKRArdt iDMHNx1OTA9VjExN/t0oxxf+SMh5waEWGUPX14X7OFCNx9+F6h7Qax00L29kQBRwzfTdN3516Q2Nl /H+kjxN1x8uOa63ku2AOqMo/BZaoNwgzuh9kVYXZYHklhAJRheeSIvi85AaxymUh3S5ZxqxsDogMa fIuG6f/zoUN9b0Grd2A7rqKg4qel6jEHIE3edrTAVrpUrSZtgzkLjORJTvbOXgrq7LS2gs2MVG6u3 TIzTxNEU2BUL93hNqs+/UB78ApOeQDmBmKkpbKgo+ncNMgEBOcblTRpBzC/sZQc3JELD8xSL1zHpe fe0E06ZscmOX1laCpiBcbw==; Original-Received: from [87.69.77.57] (port=1060 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 1oJDO2-0005lV-TB; Wed, 03 Aug 2022 08:22:09 -0400 In-Reply-To: (message from Lynn Winebarger on Wed, 3 Aug 2022 05:58:17 -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:293016 Archived-At: > From: Lynn Winebarger > Date: Wed, 3 Aug 2022 05:58:17 -0400 > Cc: Eli Zaretskii , Michael Albinus , > emacs-devel > > I found the problem - when I run make in the src directory, the variables for the ELN and bin destinations are > blank, which causes the code in loadup that is supposed to make the compilation unit names into pairs to > not bother. > Maybe these two variables should get constructed in src/Makefile.in? Running make from the src directory > shouldn't result in an unusable dump file. Why are you running "make" only in 'src'? Some necessary parts of the build must also run "make" in 'lisp' and in other places. In any case, these variables cannot be defined _only_ in src/Makefile, but we could perhaps copy the definition from the top-level Makefile.in to src/Makefile.in. > I'd probably make the code in loadup either throw an error or come up with some reasonable default. If you > insist on having the final installation specified, then it should just error during the build instead of producing a > dump guaranteed to fail when loaded. Otherwise, either use some dummy values or just treat the build > directory as the install directory. 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.