Closed Thaodan closed 1 month ago
In case you didn't see it; CI fails, please look into that. Thanks!
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?
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.
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.
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.
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 builtinnative-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
.