From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51964) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gXkNA-0001kW-Ah for guix-patches@gnu.org; Fri, 14 Dec 2018 05:07:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gXkN4-00024p-B8 for guix-patches@gnu.org; Fri, 14 Dec 2018 05:07:08 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:43087) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gXkN4-00024V-6u for guix-patches@gnu.org; Fri, 14 Dec 2018 05:07:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gXkN4-0007xr-0Q for guix-patches@gnu.org; Fri, 14 Dec 2018 05:07:02 -0500 Subject: [bug#33598] Optimizations for emacs-clang-format and emacs-clang-rename Resent-Message-ID: References: <871s6l9h54.fsf@gnu.org> <87r2ekea1u.fsf@ambrevar.xyz> From: Tim Gesthuizen Message-ID: <04daca2a-705d-6255-85bd-48132879f5a8@yahoo.de> Date: Fri, 14 Dec 2018 11:06:21 +0100 MIME-Version: 1.0 In-Reply-To: <87r2ekea1u.fsf@ambrevar.xyz> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="xIXQVaBHFS5mVlLvyQFeq316V3n2h0Y5v" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Pierre Neidhardt , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 33598@debbugs.gnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xIXQVaBHFS5mVlLvyQFeq316V3n2h0Y5v Content-Type: multipart/mixed; boundary="KtXaa7t88eiMJdO05dBkRzV8KS03Y4ZmE"; protected-headers="v1" From: Tim Gesthuizen To: Pierre Neidhardt , =?UTF-8?Q?Ludovic_Court=c3=a8s?= Cc: 33598@debbugs.gnu.org Message-ID: <04daca2a-705d-6255-85bd-48132879f5a8@yahoo.de> Subject: Re: [bug#33598] Optimizations for emacs-clang-format and emacs-clang-rename References: <871s6l9h54.fsf@gnu.org> <87r2ekea1u.fsf@ambrevar.xyz> In-Reply-To: <87r2ekea1u.fsf@ambrevar.xyz> --KtXaa7t88eiMJdO05dBkRzV8KS03Y4ZmE Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi, On 14.12.2018 10:23, Pierre Neidhardt wrote: > In your implementation, you've essentially moved the 'configure phase t= o a > snippet. As I understand it, this does not change anything. What is y= our > reason for doing this? 1. Intention: Stripping the source with the snippet models more clearly that the building part is a function that maps the single elisp file to the final package. > You are also deleting all non-required files. Which saves some space i= n /tmp > indeed, but this won't change anything to the store or the resulting > substitutes, right? I don't mind this change, I just want to be clear = about > what we are trying to achieve here :) 2. Efficiency: I am not quite sure about this - maybe I am just wrong: As far as I understand it at first guix builds a source derivation and then the actual package derivation. Even when the source derivation is not stored in the store it can be substituted. If this is the case we can save some bandwith / disk space / build time by moving the file stripping to the source snippet. On my machine the most time during the build process is spend unpacking the clang source. > Last, the factorization into package-from-clang-elisp-file: this is a g= ood idea, > and I would make it even more generic. Simply rename your function >=20 > package-elisp-from-package >=20 > (or something like that) and make "clang" a parameter. Then we can use= this > function in other packages like emacs-agda2-mode. I also thought about this but could not find another situation where this was applicable. In which module should such a function go? What would definitely be nice is that such a function can encapsulate the emacs stuff so that we do not need any other emacs related modules imported in (gnu packages llvm) for example. > Am I making sense? What do you think? Yes. Maybe we should add some reasoning to the commit message then? Depends on whether we just want a description of the changes in a commit message or also some reasoning if things might be unclear. I think that package-elisp-from-package is a really good idea. Without seeing the function definition it is really hard to figure out why it needs the arguments it needs and what their purposes are. Maybe we want to make the arguments keyword arguments if it becomes more generic so its usage is more intuitive. The first two patches are debatable though. If there is a particular reason against them (unnecessary changing without benefits included) we might want to not merge them. Tim. --KtXaa7t88eiMJdO05dBkRzV8KS03Y4ZmE-- --xIXQVaBHFS5mVlLvyQFeq316V3n2h0Y5v Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEKUiC5+8BRKEri5fa0uWPaa77GdUFAlwTgKMACgkQ0uWPaa77 GdWKbwgApsTYDe9EG5r9e3k6T+9jr7yTLlSE367PxZ4q/hjqDV0pPz6708lGoZCd FMx1I0W2bBS6+L3ukpE9ROHrhRes0B7N7sKqmVYFqZRnfpGsNXKOhjUTUAKFfSl1 J4rVWmM4erXwRAUJ7vIqRkQVR6IG7oUh3i3BiQ0Uwbm3KH77+VjP+Hq10cW/JmR0 ECehESZKAvB97HoBNHYgCcRNfu2Fp2HqkAylIy0PbQvppayy/4XduUYsHnbjpsqi Bs6sR6GIjf0p6BGPsMrRFVbg9Dm1ViOHk0IFV7wLd0r1JVbd0w4ybTs6n6upffS3 1BBvwAUYQERiRxu9kYweoalV6BI6bg== =6Lp0 -----END PGP SIGNATURE----- --xIXQVaBHFS5mVlLvyQFeq316V3n2h0Y5v--