Re: New branch 201906

[Boruch Baum <boruch_baum@xxxxxxx>]

On 2019-06-18 08:10, Katsumi Yamaoka wrote:
> >> In [emacs-w3m:13457]
> >> On Mon, 17 Jun 2019 16:12:26 +0900, Katsumi Yamaoka wrote:
> >>> Tested and tweaked the code so that `make slow' with Emacs 25.1,
> >>> 26.1, 26.2.90, and 27.0.50 may issue no warning.
>
> >> Sorry.  Not `make slow' but `make very-slow' that compiles the
> >> .el files one by one individually.
>
> `one by one individually' means to run Emacs with -q and some
> arguments (that includes --eval '(push "." load-path)'), byte-
> compile *an* .el file, and exit Emacs.  This way is applied for
> all the .el files.  Moreover, `very-slow' does it in two passes,
> one is that .el files other than the one beeing byte-compiled
> are not byte-compiled (there is no .elc file), and the other is
> that .el files other than the one beeing byte-compiled have been
> all byte-compiled (only the .elc file for the one being compiled
> is absent).  If w3m-foo.el uses the features that cl-lib provides
> whereas it does not have (eval-when-compile (require 'cl-lib)),
> it will be compiled successfully in the first pass if w3m-foo.el
> requires w3m-bar and it has (eval-when-compile (require 'cl-lib)),
> however it will fail in the second pass since eval-when-compile
> lines are not in the w3m-bar.elc file.  Then we get to know that
> w3m-foo.el needs to have (eval-when-compile (require 'cl-lib)).
> The second pass of `very-slow' is significant, the first pass is
> existent for mainly byte-compiling all the .el files.  What we
> aime at is to ensure any .el file to be byte-comipled with no
> constraint.  `very-slow' takes a long time, so it is named so.
> `slow' is similar to the first pass of `very-slow', just `make'
> does byte-compiling all the .el files in one Emacs process.

Thanks for the explanation. So, 'slow' and 'very-slow' are both
commands added to Makefile.in. That's a very useful feature; maybe it
should be mentioned in the readme as a build option?

BTW, I see that the readme was modified to remove its early copyright
date and only have the current year: it should always include the
original year. Also, documentation and other "literature" aren't proper
material to be licensed by the GPL, because the GPL is specific to
software. The correct alternative is some form of "creative commons"
license. There exist many versions of the "creative commons", so you
would need to decide and pick whichever one you prefer.

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0