[bug#33598] Optimizations for emacs-clang-format and emacs-clang-rename

[Pierre Neidhardt]

> 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/

signature.asc
Description: PGP signature