>>>>> Max Nikulin <maniku...@gmail.com> writes:

    > On 22/04/2023 14:51, Colin Baxter wrote:
    >>>>>>> Max Nikulin writes:
    >> > On 21/04/2023 23:17, Colin Baxter wrote:
    >> > emacs -Q -l org-agenda Only message and scratch buffers
    >> present.

    > C-h e to check messages, but since errors or warnings buffer does
    > not appear it should be OK.

    >> >> 1. emacs <RET> > Till `org-reload' C-c C-x ! at the step 10
    >> org is not > involved. Does you init file loads some Org
    >> component or some Org > buffer is created at startup? To be sure
    >> > M-: (featurep 'org) "No match."

    > I would expect either nil or t. Did you press M-x that is
    > `execute-extended-command' instead of M-: that is
    > `eval-expression'?  Alternatively you may execute in in the
    > *scratch* buffer

    >     (featurep 'org)

    > and C-j or C-x C-e when cursor is immediately after the closing
    > parenthesis.


Sorry, my mistake. I didn't follow your recipe exactly. If enter
(featurep 'org) in the scratch buffer and do C-j then I get nil.


    >> >> 2. M-x vc-dir <RET> 3. Navigate to ~/git/org-mode.  4. + (to
    >> >> pull) 5. M-x compile <RET> 6. make clean <RET> 7. make <RET>

    >> In the case of build org-mode, I first select "make clean" from
    >> the history of "M-x compile". Then I do "M-x compile" again and
    >> select "make" from the history. The effect is the same using the
    >> terminal, except the outputs are now contained in emacs buffers.

    > Thank you for explanation. For some reason I believed that M-x
    > compile invokes make without additional prompt. So

    >     make clean; make

    > sounds perfectly reasonable.

    >> >> 8. In an eshell buffer navigate to ~/git/emacs/lisp.  >> Typo!
    >> I meant navigate to ~/git/org-mode/lisp.  >> 9. rm *.elc <RET> >
    >> Why did you decided to manually delete *.elc files? I have lost
    >> at > which step you got the warning. I expect that "make clean"
    >> should > remove .elc files.  If I don't delete the elc files in
    >> ~/git/org-mode/lisp after the first build then I do get errors.

    > Do you mean that it happens on each update?


Yes. However, there was a time several months ago when I needed only
build org-mode once to update it successfully. Something then changed in
org-mode such that initially updated .elc files caused an error. I
subsequently discovered that if a went through the build process twice,
removing the .elc files after the first build, they would be accepted at
the second build. 


    > No .elc files should
    > survive "make clean". I have not tried to reproduce it accordingly
    > to your steps, but I have seen something strange related to .el
    > and .elc files while experimenting with package.el.

    > https://orgmode.org/worg/dev/org-build-system.html#orgd21575b
    > "Compatibility and Convenience" and
    > 
https://orgmode.org/worg/org-faq.html#keeping-current-with-Org-mode-development
    > suggests that

    >     make uncompiled

    > may be a shorter path to the same point.

    > However accordingly to your description I expect that you do not
    > have Org loaded yet. If you can not load compiled org now it
    > should cause an error after emacs restart as well.


Org-mode is already loaded, that is the git version of org that I am about to
update is already loaded. If I C-j

--8<---------------cut here---------------start------------->8---
(car (assoc "/org-loaddefs.el" load-history (lambda (a b)
(string-match-p b a))))
--8<---------------cut here---------------end--------------->8---

in a scratch buffer then I get "~/git/org-mode/lisp/org-loaddefs.el". I
update org-mode during a normal emacs session that may have run over 
one or two days, during which time I will have used org-agenda, clocked
in and out of various times and perhaps used org-export.

Best wishes,

Colin.


Reply via email to