Option to skip byte compilation of package's .el files

[FrauH0lle]

Hey @raxod502

Would it be possible to have an option in straight.el which skips byte compilation and have only the .el files symlinked into the build folder?

So one could write (just an example):

(use-package foo
    :straight (:no-byte-compile t)
    ....

[raxod502]

I don't object to adding such an option, but only if there's a use case for it. What problem would this solve?

[FrauH0lle]

Thanks for your reply!

In my eyes this option

• would be a good addition to straight.el's package build option. The user would have a full set of options to control the way a package is handled: to just clone, but not build a package (:no-build), to build with autoloads but not to byte-compile (:no-byte-compile) and maybe even without autoloads and without byte-compilation (:no-autoloads, :no-byte-compile). Beside the offered user control, I imagine that this could be helpful for a user debugging his/her init file.

• would help users which share their .emacs.d across different emacs versions (e.g. via Dropbox) which would require them to recompile each time they switch their PC. But I don't think a lot of people handle their .emacs.d this way, so this is a minor point.

• would help me in my personal and specific problem. I use straight.el to load quiet a few of custom helper functions, most of them are autoloads. I want to do that early in my init.el so that the following use-package declarations can use these functions. straight.el does a great job and correctly collects all autoloads, however the compilation happens a too early and thus, some of the generated .elc files miss some of the defined functions because their requirements are not met. For example, some of the helpers require evil to be available but this package is loaded a bit later. These functions are missing in the .elc file and as soon as another use-package declaration uses one of these functions, emacs aborts because this function is void.

I tried my luck with the following implementation, inspired by straight--generate-package-autoloads

(setq straight--build-keywords
      '(:local-repo :files :no-autoloads :no-byte-compilation))


(defcustom straight-disable-byte-compilation nil
  :type 'boolean)

(cl-defun straight--byte-compile-package (recipe)
  "Byte-compile files for the symlinked package specified by RECIPE.
RECIPE should be a straight.el-style plist. Note that this
function only modifies the build folder, not the original
repository. TEST: has `:no-byte-compilation' added."
  (when (straight--plist-get recipe :no-byte-compilation straight-disable-byte-compilation)
    (cl-return-from straight--byte-compile-package))
   ..... )

And it appears to work, even though I should say that I am still an emacs-lisp noob.

Thank you for your time and consideration.

[raxod502]

Thanks for your detailed analysis! I very much appreciate it :)

As for sharing .emacs.d across multiple Emacs versions, I think the better solution is #274 and setting the build directory depending on the current Emacs version. (In fact, I think this should perhaps be done by default once #300 is completed.)

As for dealing with macro problems, I feel your pain. The UX for byte-compilation is very bad. However, in my experience, there is always a way of working around the problem without disabling byte-compilation, even if it takes a while to figure out. And this is desirable: after all, byte-compilation improves startup time.

I don't personally byte-compile my init-file (yet), so I haven't really investigated how straight.el interacts with byte-compilation. I imagine that one must follow some best practices or use some extra setup code when bootstrapping in order to make sure the byte-compiler has access to all the symbols it needs. I'd definitely be interested in hearing how it goes.

However, if you are still inexperienced with Emacs Lisp, this might not be worth your time. I have several years of experience and I still find it extremely confusing.

In any case, allowing one to disable byte-compilation sounds like a perfectly reasonable idea. Since it is a trivial change, I implemented it in the above commit.

[FrauH0lle]

Thanks a lot for implementing my proposal!

Keep up the great work with straight.el and el-patch!