> 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. I am not sure sure about this. Ludovic, do we have such a thing as "source substitutes"? > I also thought about this but could not find another situation where > this was applicable. Look for "emacs-build-system" in files other than emacs.scm. It's used in quite a few places. > In which module should such a function go? Hmmm, I guess either guix/build/emacs-utils.scm, or gnu/packages/emacs.scm. > 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. What emacs stuff? You mean the build system? > 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. Well, the reasoning above is mostly a nit. What matters most is - Efficiency, if it really works. - The abstraction function. > 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. Sure, that's the very purpose of keyword arguments, make code readable. If it reads like an English sentence, it's a win! > 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. Even if the efficiency point is moot, the abstraction is more than welcome: try it on at least one more package, then it will save lots of package code. I'm all for it! :) -- Pierre Neidhardt https://ambrevar.xyz/