search

emacscollective / borg

Assimilate Emacs packages as Git submodules
https://emacsmirror.net/manual/borg
GNU General Public License v3.0
255 stars 28 forks source link

Ensure native-compilation support can be found in Emacs 30 and refactor slightly #161

Closed Thaodan closed 1 month ago

Thaodan commented 1 month ago

The foundp check on each of the native-compilation functions failed on Emacs 30 without requiring comp.el. Further it's better to use the builtin native-comp-available-p function instead of using foundp as it doesn't depend on potentially version specific semantic as a function might not be found but native-compilation would be still available.

Fixes Emacs 30.0.50 does not support native compilation.

tarsius commented 1 month ago

In case you didn't see it; CI fails, please look into that. Thanks!

Thaodan commented 1 month ago

Using (native-compile-p) broke the byte-compiler hack for (and). However using (fboundp #'function) also breaks the hack.

I can't get the check for native-compilation without fboundp to work outside of Emacs 28 or greater.

Should I restore the use of foundp? How long do you want to keep supporting Emacs 27?

Thaodan commented 1 month ago

Regarding your recent commit: native-compile-async is also defined in comp-run.el although it is bound without requiring com-run.el. That doesn't fix async native compilation thou.

tarsius commented 1 month ago

I've tested synchronous compilation using make native and it worked. This is the only method I recommend (beside not forcing borg to do native compilation and instead relying on emacs to later perform the native compilation, which is what the emacs maintainers intended and which I recommend even more).

I strongly discourage forcing borg to do asynchronous native compilation. When using make native the consequence of doing it asynchronously is that the main emacs instance finishes before all the instances that perform native compilation is done. It then terminates those instance, meaning that some (most) libraries won't be natively compiled. Forcing borg to perform asynchronous native compilation in interactive sessions also doesn't make sense: if borg doesn't do it, then emacs will do it anyway. Making borg do it just complicates matters and risks introducing issues.

So why does borg support it anyway (assuming it's not really broken)? Well some user(s?) really wanted to do it despite my reasoning, which I repeated above. So I implemented it, but recommend against using it.

Thaodan commented 1 month ago

Jonas Bernoulli @.***> writes:

discourage forcing borg to do asynchronous native compilation. When using make native the consequence of doing it asynchronously is that the main emacs instance finishes before all the instances that perform native compilation is done. It then terminates those instance, meaning that some (most) libraries won't be natively compiled.

The documentation of native-compile-async mentions files instead of file and spawns jobs according to the setting of native-comp-async-jobs-number. Would it be better to let Emacs itself decide the order of compilation and thous pass all files instead of passing each file individually?

Forcing borg to perform asynchronous native compilation in interactive sessions also doesn't make sense: if borg doesn't do it, then emacs will do it anyway. Making borg do it just complicates matters and risks introducing issues.

I assume the intention of such users could be to compile native code ahead of time after each update.

So why does borg support it anyway (assuming it's not really broken)? Well some user(s?) really wanted to do it despite my reasoning, which I repeated above. So I implemented it, but recommend against using it.

Wasn't aware of the underlying issue, thanks I wasn't aware.