Below update is after I updated to the latest org master:
Ah, right ... 'make compile' uses a single Emacs instance, while 'make
single' uses a separate Emacs instance for each file.
I wasn't even doing that. I was doing M-x byte-compile-file and selecting org.el.
That gives me (without applying your patch):
Compiling file /home/kmodi/stow/pub_dotfiles/emacs/dot-emacs.d/elisp/org-mode/lisp/org.el at Fri May 26 14:04:52 2017
In org-goto-map:
org.el:7412:9:Warning: function org-goto-map used to take 0+ arguments, now
takes 0
In org-todo:
org.el:12398:12:Warning: function org-todo used to take 0+ arguments, now
takes 0-1
In org-store-log-note:
org.el:13635:8:Warning: function org-store-log-note used to take 0+ arguments,
now takes 0
In org-at-timestamp-p:
org.el:17909:40:Warning: reference to free variable
‘org-agenda-include-inactive-timestamps’
In org-self-insert-command:
org.el:19910:32:Warning: function org-self-insert-command used to take 0+
arguments, now takes 1
With 'make single' on master, I get a compile error due to the
eval-when-compile's added in 53ee147f4 (Add support for new switches to
org-get-heading, 2017-01-17) and 6dc6eb3b0 (Fix failing test,
2017-01-19).
In toplevel form:
org.el:7914:51:Error: Symbol’s value as variable is void: org-comment-string
I get that too.
Your patch is only the appropriate fix if we're confident that
org-agenda will be loaded at the time that the
org-agenda-include-inactive-timestamps code path of org-at-timestamp-p
is executed. Otherwise, we're just silencing a warning about a possible
run-time void variable error. Have you looked this?
No, I didn't.. your bound-and-true-p patch makes more sense.
So.. should we consider the warnings output by simple byte-compile-file? Even if not, the warnings do not make sense.. just taking this example:
In org-goto-map:
org.el:7412:9:Warning: function org-goto-map used to take 0+ arguments, now
takes 0
Nowhere is org-goto-map defined to take 0+ arguments (meaning have "&optional arg" as signature) and then redefined to have 0 arguments (which is the actual case). Wondering why the compiler thinks that. I had a quick look at byte-compile-arglist-warn function that outputs this warning.. but couldn't understand the logic for sig1 in there.