Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

straight is rebuilding org on every single launch of emacs #624

Closed
aspiers opened this issue Nov 1, 2020 · 68 comments
Closed

straight is rebuilding org on every single launch of emacs #624

aspiers opened this issue Nov 1, 2020 · 68 comments
Labels
bug build system external command org-mode

Comments

@aspiers
Copy link
Contributor

aspiers commented Nov 1, 2020

What's wrong

I am now seeing a Building org... message from straight.el every single time I launch emacs. Presumably this is related to the recent addition of support for :build steps. Since the build steps do things like compiling the whole manual, this takes something like one or two minutes and therefore drastically increases the waiting time before emacs is ready for use.

Directions to reproduce

  • Launch emacs with a config which uses straight.el to load org ;-)

I've added some debug to the bit of straight-use-package which calculates modified and it is showing that (straight--package-might-be-modified-p recipe no-build) returns 98, so presumably it's something in there which is going wrong.

But if you can't reproduce this and it's looking like this might be related to some peculiarity of my config, given that I have a decent amount of elisp hacking experience, rather than trying to create a minimal test case I guess it might be quicker if you can confirm I'm on the right track and I'll keep digging in straight--package-might-be-modified-p.

Version information

  • Latest master of straight.el
  • Emacs version: 27.1
  • Operating system: openSUSE Tumbleweed
@aspiers aspiers added the bug label Nov 1, 2020
@progfolio
Copy link
Contributor

progfolio commented Nov 1, 2020 •
edited
Loading

Try running the following test case twice.
It will build straight/Org in a clean environment in /tmp/org-rebuild-test.straight on the first execution.
Once that finishes, you should see something similar to the first Output below.
Then run it again. It should run much faster (hopefully Org is not being rebuilt) the second time and the Output should be similar to the second Output block below.

Test Case 
(straight-bug-report
  :user-dir "org-rebuild-test.straight"
  :preserve t
  :post-bootstrap 
  (straight-use-package 'org))
  • Test run at: 2020-11-01 16:16:52
  • system-type: gnu/linux
  • straight-version: prerelease (HEAD -> feat/el-get-recipe-support, fork/feat/el-get-recipe-support) 9aa6141 2020-10-31
  • emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.17.3, Xaw3d scroll bars) of 2020-10-31
Output 
Bootstrapping straight.el...
Bootstrapping straight.el...done
Rebuilding all packages due to build cache schema change
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...
Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> develop, origin/develop) 68dade0 2020-10-24
Cloning org...
Cloning org...done
Building org...
Building org...done
Output<2> 
Test run with version: prerelease (HEAD -> develop, origin/develop) 68dade0 2020-10-24

@aspiers
Copy link
Contributor Author

aspiers commented Nov 2, 2020

Thanks a lot for the pointers! I'm unsure if you meant to run within an existing emacs or a fresh emacs -Q or something else? If I just eval-defun that sexp then I only see:

Testing straight.el in directory: /tmp/org-rebuild-test.straight

and nothing else happens.

OTOH if you meant with emacs -Q or similar then I am unsure how the bootstrapping is supposed to work because of course straight-bug-report is not defined yet.

@progfolio
Copy link
Contributor

Sorry, I should have been clearer.
You'll want to run that in a regular Emacs session. It will start another Emacs process that runs the test. When it finishes, a buffer with the test's output (*straight-bug-report-process*) should pop up with the results. The test will install straight and Org, so it should take about as long as it does on your normal system.

@progfolio
Copy link
Contributor

If you're not seeing anything after a reasonable amount of time, you can add to the test to make it an interactive emacs process:

(straight-bug-report
  :interactive t
  :user-dir "org-rebuild-test.straight"
  :preserve t
  :post-bootstrap 
  (straight-use-package 'org))

You can also check to see if /tmp/org-rebuild-test.straight exists on disk.

@aspiers
Copy link
Contributor Author

aspiers commented Nov 2, 2020

@progfolio commented on November 2, 2020 7:37 PM:

Sorry, I should have been clearer.
You'll want to run that in a regular Emacs session.

That's what I did. It just outputs the message above in the minibuffer and nothing else happens... Ahah, eventually I saw this in the minibuffer:

error in process sentinel: unless: Symbol’s value as variable is void: interactive

It happened so much later (minutes later) that I didn't realise it was related. But running it again showed the connection. After enabling debug-on-error I get this:

Debugger entered--Lisp error: (void-variable interactive)
  (if interactive nil (unless raw (straight-bug-report--format report)) (switch-to-buffer-other-window straight-bug-report--process-buffer))
  (unless interactive (unless raw (straight-bug-report--format report)) (switch-to-buffer-other-window straight-bug-report--process-buffer))
  (lambda (_process _event) (unless interactive (unless raw (straight-bug-report--format report)) (switch-to-buffer-other-window straight-bug-report--process-buffer)) (unless preserve-files (when (file-exists-p temp-emacs-dir) (delete-directory temp-emacs-dir 'recursive))))(#<process *straight-bug-report-process*> "finished\n")

@progfolio
Copy link
Contributor

progfolio commented Nov 2, 2020 •
edited
Loading

Sounds like you may be executing it without lexical binding enabled. I patched this last night so that you'll get a more informative, immediate, user-error in this case. Try evaling in a buffer which has lexical-binding enabled.

@aspiers
Copy link
Contributor Author

aspiers commented Nov 2, 2020

Ahah yes! Works now, many thanks :-) Yes, on second run it doesn't rebuild org. So does that mean the issue is specific to my environment? If so, what's the next step - my original suggestion of digging deeper in straight--package-might-be-modified-p?

@progfolio
Copy link
Contributor

progfolio commented Nov 2, 2020 •
edited
Loading

So does that mean the issue is specific to my environment?

Yes, that's my inclination. Test case runs for me without subsequent rebuilds.
Stepping through straight--package-might-be-modified-p could be a good lead, but it might just be a case of another package marking buffers modified, too.

Some other useful info to have:

  • value of straight-check-for-modifications
  • recipe for Org in your init file and recipe for Org as returned by straight-get-recipe.
  • output of (gethash "org-plus-contrib" straight--build-cache) (or "org" if you're not using "org-plus-contrib")

@aspiers
Copy link
Contributor Author

aspiers commented Nov 5, 2020

Thanks a lot - super busy at the moment but I'll get back to this soon!

@rileyrg
Copy link

rileyrg commented Nov 8, 2020 •
edited
Loading

I have been having similar issues with org-plus-contrib. I have resorted to delete all content in straight/ but it still crops up. I'll follow the suggestions here too and see what happens. Interestingly doing a manual eval from withing my init file (C-x C-e outside use-package form) stopped this for a while. It's very annoying and very confusing ;)
Screenshot from 2020-11-08 10-32-51

@progfolio
Copy link
Contributor

progfolio commented Nov 8, 2020 •
edited
Loading

@rileyrg please try running the test case here in a buffer with lexical binding enabled:

#624 (comment)

Any other relevant info, such as your org use-package declaration and the values I mentioned here:

#624 (comment)

will be helpful as well.

@progfolio
Copy link
Contributor

@aspiers I noticed you are using use-package's :ensure keyword alongside the :straight keyword:

https://github.com/aspiers/emacs/blob/9eeee3e99e5e9129bb63a16e7fe81452bd0025bc/.emacs.d/init.d/as-org-mode.el#L8

This could cause a conflict w straight since :ensure utilizes package.el. Does removing that help?

@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020

Nice idea but it doesn't help. However @rileyrg's screenshot above made me wonder why I was seeing Building org... rather than Building org-plus-contrib... so I looked closer and actually saw both in the *Messages* buffer, but the former is the one which takes a long time.

This suggests to me that maybe this issue is related to the way I'm loading org-plus-contrib.

@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020

Hrm, I changed some stuff and now both builds are taking a long time ... :-/

If I have

(use-package org
  :straight org-plus-contrib
  ...)

does that mean that I should be referencing org or org-plus-contrib in clauses such as this :after section?

(use-package orgit
  :after (org-plus-contrib magit))

@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020 •
edited
Loading

@progfolio commented on November 2, 2020 10:06 PM:

Some other useful info to have:

  • value of straight-check-for-modifications

The default: (find-at-startup find-when-checking) (incidentally, checking this led to #628)

  • recipe for Org in your init file and recipe for Org as returned by straight-get-recipe.

org or org-plus-contrib? In any case, here they both are:

`(org :type git :repo "https://code.orgmode.org/bzg/org-mode.git" :local-repo "org" :build ,(let ((make (if (eq system-type 'berkeley-unix) "gmake" "make")) (emacs (concat "EMACS=" invocation-directory invocation-name))) `(,make "oldorg" ,emacs)))

`(org-plus-contrib :type git :repo "https://code.orgmode.org/bzg/org-mode.git" :local-repo "org" :files (:defaults "contrib/lisp/*.el") :build ,(let ((make (if (eq system-type 'berkeley-unix) "gmake" "make")) (emacs (concat "EMACS=" invocation-directory invocation-name))) `(,make "oldorg" ,emacs)))
  • output of (gethash "org-plus-contrib" straight--build-cache) (or "org" if you're not using "org-plus-contrib")
("2020-11-08 11:21:04" nil (:type git :repo "https://code.orgmode.org/bzg/org-mode.git" :local-repo "org" :files (:defaults "contrib/lisp/*.el") :build ("make" "oldorg" "EMACS=/usr/bin/emacs") :package "org-plus-contrib"))

@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020

@aspiers commented on November 8, 2020 11:19 AM:

Hrm, I changed some stuff and now both builds are taking a long time ... :-/

If I have

(use-package org
  :straight org-plus-contrib
  ...)

does that mean that I should be referencing org or org-plus-contrib in clauses such as this :after section?

(use-package orgit
  :after (org-plus-contrib magit))

Oh wow, I changed all of these from org-plus-contrib to org and now the constant rebuilding is gone!

aspiers added a commit to aspiers/emacs that referenced this issue Nov 8, 2020
@aspiers
Fix constant rebuilding of org on startup
5ff9e5f 
See radian-software/straight.el#624
@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020

I guess there are two remaining questions:

  1. @rileyrg does this help you fix it?
  2. Are there any improvements which could be made to the docs in this regard?

@rileyrg
Copy link

rileyrg commented Nov 8, 2020 via email •
edited
Loading

@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020

This issue describes the problem where it is rebuilt, undesirably, on subsequent restarts. Are you saying you want the opposite behaviour? It's not supposed to rebuild unless something changes which requires the rebuild.

@rileyrg
Copy link

rileyrg commented Nov 8, 2020 •
edited
Loading

This issue describes the problem where it is rebuilt, undesirably, on subsequent restarts. Are you saying you want the opposite behaviour? It's not supposed to rebuild unless something changes which requires the rebuild.

I am saying that it was constantly rebuilding up to when I started emacs again, watched it rebuild org-plus-contrib yet again, opened my config file and manually eval'ed the org use-package form. Then, when I quit and restarted emacs it didn't rebuild. Strange eh? But it might trigger an "aha" in someone who knows this stuff better than me.

My org-mode use package

@rileyrg
Copy link

rileyrg commented Nov 8, 2020 •
edited
Loading

FYI, I have to give up now because of other things today, but I did a complete straight wipe out and restarted emacs. I had to comment out the boxquote.el form.

     (use-package boxquote
       :bind
       ("C-S-r" . boxquote-region))

When I tried to evaluate it after here is the stack. I've a nasty feeling this is going to be something to do with the recipe format but I've no idea. All the other GitHub hosted repos clone just fine.

Debugger entered--Lisp error: (error "Failed to run \"git\"; see buffer *straight-process*") signal(error ("Failed to run \"git\"; see buffer *straight-process*")) error("Failed to run %S; see buffer %s" "git" "*straight-process*") straight--get-call-raw("git" "clone" "--origin" "origin" "--branch" "master" "--no-checkout" "git@github.com:davep/boxquote.el.git" "/home/rgr/.emacs.d/straight/repos/boxquote.el/") apply(straight--get-call-raw "git" ("clone" "--origin" "origin" "--branch" "master" "--no-checkout" "git@github.com:davep/boxquote.el.git" "/home/rgr/.emacs.d/straight/repos/boxquote.el/")) straight--get-call("git" "clone" "--origin" "origin" "--branch" "master" "--no-checkout" "git@github.com:davep/boxquote.el.git" "/home/rgr/.emacs.d/straight/repos/boxquote.el/") straight-vc-git--clone-internal(:depth full :remote "origin" :url "git@github.com:davep/boxquote.el.git" :repo-dir "/home/rgr/.emacs.d/straight/repos/boxquote.el/" :branch "master" :commit nil) straight-vc-git-clone((:type git :flavor melpa :host github :repo "davep/boxquote.el" :package "boxquote" :local-repo "boxquote.el") nil) apply(straight-vc-git-clone ((:type git :flavor melpa :host github :repo "davep/boxquote.el" :package "boxquote" :local-repo "boxquote.el") nil)) straight-vc(clone git (:type git :flavor melpa :host github :repo "davep/boxquote.el" :package "boxquote" :local-repo "boxquote.el") nil) straight-vc-clone((:type git :flavor melpa :host github :repo "davep/boxquote.el" :package "boxquote" :local-repo "boxquote.el")) straight--clone-repository((:type git :flavor melpa :host github :repo "davep/boxquote.el" :package "boxquote" :local-repo "boxquote.el") nil) #f(compiled-function () #<bytecode 0x157cc17d2bb5>)() straight--transaction-exec(use-package-\(:type\ git\ :flavor\ melpa\ :host\ github\ :repo\ \"davep/boxquote\.el\"\ :package\ \"boxquote\"\ :local-repo\ \"boxquote\.el\"\)-nil-nil :now #f(compiled-function () #<bytecode 0x157cc17d2bb5>)) straight-use-package(boxquote) (progn (straight-use-package 'boxquote) (defvar use-package--warning101 #'(lambda (keyword err) (let ((msg (format "%s/%s: %s" ... keyword ...))) (display-warning 'use-package msg :error)))) (condition-case err (progn (if (fboundp 'boxquote-region) nil (autoload #'boxquote-region "boxquote" nil t)) (let* ((name "C-S-r") (key (if (vectorp name) name (read-kbd-macro name))) (kmap (if (and nil ...) (symbol-value nil) nil)) (kdesc (cons (if ... name ...) (if ... nil ...))) (binding (lookup-key (or kmap global-map) key))) (let ((entry (assoc kdesc personal-keybindings)) (details (list ... ...))) (if entry (setcdr entry details) (add-to-list 'personal-keybindings (cons kdesc details)))) (define-key (or kmap global-map) key #'boxquote-region))) ((debug error) (funcall use-package--warning101 :catch err)))) eval((progn (straight-use-package 'boxquote) (defvar use-package--warning101 #'(lambda (keyword err) (let ((msg ...)) (display-warning 'use-package msg :error)))) (condition-case err (progn (if (fboundp 'boxquote-region) nil (autoload #'boxquote-region "boxquote" nil t)) (let* ((name "C-S-r") (key (if ... name ...)) (kmap (if ... ... nil)) (kdesc (cons ... ...)) (binding (lookup-key ... key))) (let ((entry ...) (details ...)) (if entry (setcdr entry details) (add-to-list ... ...))) (define-key (or kmap global-map) key #'boxquote-region))) ((debug error) (funcall use-package--warning101 :catch err)))) nil) elisp--eval-last-sexp(nil) eval-last-sexp(nil) funcall-interactively(eval-last-sexp nil) call-interactively(eval-last-sexp nil nil) command-execute(eval-last-sexp)

@aspiers
Copy link
Contributor Author

aspiers commented Nov 8, 2020

That error simply means the git clone failed, which could be down to a broken internet connection or some other misconfiguration of your git setup. I suggest manually trying the git clone command listed in the error to see if it's even related to emacs.

@rileyrg
Copy link

rileyrg commented Nov 8, 2020 via email

@rileyrg
Copy link

rileyrg commented Nov 8, 2020

I just did a clean start ensuring emacs was opening my key properly for ssh-agent. the git@github boxquote.el clone still failed from inside emacs. I'm removing it now so I can get on. Sorry I cant provide more info atm.

@progfolio
Copy link
Contributor

@rileyrg: I get the git failure as well. The error being thrown points to the *straight-process* buffer which reveals:

Cloning into '/home/n/.emacs.d/straight/repos/boxquote.el'...
fatal: Remote branch master not found in upstream origin

It appears boxquote.el's default branch is now "main":

https://github.com/davep/boxquote.el

either of these should fix the problem while we wait for #543 to land:

(straight-use-package '(boxquote :branch "main"))

or

(use-package boxquote
  :straight (:branch "main"))

@progfolio
Copy link
Contributor

progfolio commented Nov 8, 2020 •
edited
Loading

@aspiers: Thank you for taking the time to look into this more and for #628. Glad to see you were able to resolve the issue. I agree we could do better by providing more specific configuration examples in the docs for popular packages like Org. If you have ideas, please let us know.

I think the changes planned for Org 9.5 (#620) may help alleviate some of this confusion.

@kevinjfoley
Copy link

Looks like you have a plan of action on this @progfolio, sharing an additional test case below in case it's helpful.

Also it seems like some people have resolved when testing with straight-bug-report only to still experience the issue with their config. I found that if I changed the test case code without using a fresh :user-dir it seemed to trick straight-bug-report. But as soon as I ran the same test case twice in a fresh :user-dir the problem would present it self again.

Not sure what the cause is but thought it might be an explanation why the problem seems to go away when testing.

Test Case 
(straight-bug-report
  :user-dir "org-contrib-rebuild-test.straight"
  :preserve t
  :post-bootstrap 
  (straight-use-package 'use-package)
  (use-package org :straight
    (org-plus-contrib :repo "https://code.orgmode.org/bzg/org-mode.git" :local-repo "org" :files
      (:defaults "contrib/lisp/*.el")))
  (use-package org-super-agenda :straight t :after org))
  • Test run at: 2020-12-16 09:16:41
  • system-type: darwin
  • straight-version: prerelease (HEAD -> develop, origin/develop) 0f283e2 2020-11-04
  • emacs-version: GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H2)) of 2020-12-12
First Run Output 
Bootstrapping straight.el...
Bootstrapping straight.el...done
Rebuilding all packages due to build cache schema change
Looking for gnu-elpa-mirror recipe → Cloning melpa...
Looking for gnu-elpa-mirror recipe → Cloning melpa...done
Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...
Looking for emacsmirror-mirror recipe → Cloning gnu-elpa-mirror...done
Looking for emacsmirror-mirror recipe → Cloning el-get...
Looking for emacsmirror-mirror recipe → Cloning el-get...done
Looking for straight recipe → Cloning emacsmirror-mirror...
Looking for straight recipe → Cloning emacsmirror-mirror...done
Building straight...
Building straight...done

Test run with version: prerelease (HEAD -> develop, origin/develop) 949a0a7 2020-12-13
Cloning use-package...
Cloning use-package...done
Building use-package...
Building use-package → Building bind-key...
Building use-package → Building bind-key...done
Building use-package...
Building use-package...done
Cloning org (for org-plus-contrib)...
Cloning org (for org-plus-contrib)...done
Building org-plus-contrib...
Building org-plus-contrib...done
Cloning org-super-agenda...
Cloning org-super-agenda...done
Building org-super-agenda...
Building org-super-agenda → Cloning s.el...
Building org-super-agenda → Cloning s.el...done
Building org-super-agenda → Building s...
Building org-super-agenda → Building s...done
Building org-super-agenda → Cloning dash.el...
Building org-super-agenda → Cloning dash.el...done
Building org-super-agenda → Building dash...
Building org-super-agenda → Building dash...done
Building org-super-agenda → Building org...
Building org-super-agenda → Building org...done
Building org-super-agenda → Cloning ht.el...
Building org-super-agenda → Cloning ht.el...done
Building org-super-agenda → Building ht...
Building org-super-agenda → Building ht...done
Building org-super-agenda → Cloning ts.el...
Building org-super-agenda → Cloning ts.el...done
Building org-super-agenda → Building ts...
Building org-super-agenda → Building ts...done
Building org-super-agenda...
Building org-super-agenda...done
Second Run Output 
Test run with version: prerelease (HEAD -> develop, origin/develop) 949a0a7 2020-12-13
Building org-plus-contrib...
Building org-plus-contrib...done
Building org...
Building org...done

progfolio added a commit to progfolio/straight.el that referenced this issue Dec 21, 2020
@progfolio
Org recipes: prevent duplicate byte-compilation/autoloads
e030338 
Org's makefile takes care of this work.
Doing it twice is not only wasteful, but can cause errors (see: radian-software#624)
@progfolio progfolio mentioned this issue Dec 21, 2020
Merged
@raxod502 raxod502 mentioned this issue Dec 21, 2020
Closed
@progfolio progfolio mentioned this issue Dec 21, 2020
Merged
progfolio added a commit to progfolio/straight.el that referenced this issue Dec 23, 2020
@progfolio
Org recipes: prevent duplicate byte-compilation/autoloads
f87fcfb 
Org's makefile takes care of this work.
Doing it twice is not only wasteful, but can cause errors (see: radian-software#624)

Use "org" as build-dir name for org-plus-contrib
Otherwise we end up with both build/org-plus-contrib and build/org
when a package declares Org as a dependency after the user has installed
org-plus-contrib.
progfolio added a commit to progfolio/straight.el that referenced this issue Dec 23, 2020
@progfolio
Org recipes: prevent duplicate byte-compilation/autoloads
9d06ead 
Org's makefile takes care of this work.
Doing it twice is not only wasteful, but can cause errors (see: radian-software#624)

Use "org" as build-dir name for org-plus-contrib
Otherwise we end up with both build/org-plus-contrib and build/org
when a package declares Org as a dependency after the user has installed
org-plus-contrib.
progfolio added a commit to progfolio/straight.el that referenced this issue Dec 23, 2020
@progfolio
Byte compile in child process
0219a4f 
Separates byte-compilation from state of running Emacs.

See: radian-software#76, radian-software#624
progfolio added a commit to progfolio/straight.el that referenced this issue Dec 23, 2020
@progfolio
Byte compile in child process
27839e2 
Separates byte-compilation from state of running Emacs.

See: radian-software#76, radian-software#624
progfolio added a commit to progfolio/straight.el that referenced this issue Dec 29, 2020
@progfolio
Org recipes: prevent duplicate byte-compilation/autoloads
177db94 
Org's `oldorg` make target duplicates straight's byte-compilation and
autoload generation.
This duplicaiton is wasteful and error-prone (see: radian-software#624)
We're going with Org's `autoloads` make target because it generates
the necessary org-version.el file as well as autoloads.
Straight handles the byte-compilation.

Use "org" as build-dir name for org-plus-contrib
Otherwise we end up with both build/org-plus-contrib and build/org
when a package declares Org as a dependency after the user has installed
org-plus-contrib.
progfolio added a commit that referenced this issue Dec 29, 2020
@progfolio
Org recipes: prevent duplicate byte-compilation/autoloads (#658)
cc21741 
Org's `oldorg` make target duplicates straight's byte-compilation and
autoload generation.
This duplicaiton is wasteful and error-prone (see: #624)
We're going with Org's `autoloads` make target because it generates
the necessary org-version.el file as well as autoloads.
Straight handles the byte-compilation.

Use "org" as build-dir name for org-plus-contrib
Otherwise we end up with both build/org-plus-contrib and build/org
when a package declares Org as a dependency after the user has installed
org-plus-contrib.
progfolio added a commit that referenced this issue Dec 31, 2020
@progfolio @raxod502
byte compile in child process (#657)
48296ba 
* Byte compile in child process

Separates byte-compilation from state of running Emacs.

See: #76, #624

Co-authored-by: Radon Rosborough <radon.neon@gmail.com>
@progfolio
Copy link
Contributor

progfolio commented Jan 2, 2021 •
edited
Loading

The latest develop branch is byte compiling in a separate process and has the altered Org mode recipes.
Hoping that takes care of this. Appreciate any testing/feedback.

@aaronjensen
Copy link
Contributor

This appears to work for me. I had to update my custom org-plus-contrib recipe to use the new built-in one, which appears to work well. Thank you!

@rileyrg
Copy link

rileyrg commented Jan 2, 2021 via email

aspiers added a commit to aspiers/emacs that referenced this issue Jan 2, 2021
@aspiers
Switch all mentions of org to org-plus-contrib
9437dae 
straight.el's built-in recipes for Org have been improved to avoid
duplication.  No need to mention org at all, just org-plus-contrib:

radian-software/straight.el#658
radian-software/straight.el#624 (comment)
@aspiers
Copy link
Contributor Author

aspiers commented Jan 2, 2021 •
edited
Loading

I just switched to (use-package org-plus-contrib) and other packages to :after org-plus-contrib and it seems to work fine.

@rileyrg
Copy link

rileyrg commented Jan 2, 2021 via email

@aspiers
Copy link
Contributor Author

aspiers commented Jan 2, 2021

If you look at the latest source, you'll see that straight.el translates both org and org-plus-contrib into recipes which start with (org ...) and both have "lisp/*.el" in their :files property, but only org-plus-contrib also has "contrib/lisp/*.el" in its :files property.

@rileyrg
Copy link

rileyrg commented Jan 2, 2021 via email

@progfolio
Copy link
Contributor

Thank you everyone for you patience and testing efforts.
Glad to see things are working. I'll consider this bug closed for now. If the issue crops up again for anyone, feel free to leave a comment and we can reopen it.

@reilyrg: I understand the confusion around Org vs "Org plus contrib". In Org 9.5, the plan (as I understand it) is to break out the contrib packages into their own separate repository.
This should simplify things and hopefully clear up some of the confusion. If you're interested in the details:

https://orgmode.org/list/87wnzfy60h.fsf@bzg.fr/

@raxod502
Copy link
Member

raxod502 commented Jan 7, 2021

Thank goodness. org-plus-contrib is quite frankly bizarre. Unfortunately, in the absence of some upstream packaging changes, I do not think it is possible to smooth over the unintuitive behavior in straight.el (really, org-plus-contrib should be a virtual package consisting of "org" and "org-contrib" separately, but there's no concept of virtual packages or anything like that).

@progfolio One thing I notice with the new recipes is that it is now possible for (straight--convert-recipe 'org-plus-contrib) to return a recipe whose package is not named org-plus-contrib -- I believe such a situation never happened before. I don't know if that would cause any problems, and clearly your implementation is working well enough so far, but I wanted to call your attention to this in case something does crop up later.

@progfolio progfolio mentioned this issue Jan 12, 2021
Merged
@aaronjensen
Copy link
Contributor

I don't know if it's something particular to my setup, but I still frequently have to rebuild org.

@aaronjensen
Copy link
Contributor

I tracked this down. Because I launch Emacs on a mac in different ways, invocation-directory and invocation-name can vary. When they vary, org rebuilds because of:

https://github.com/raxod502/straight.el/blob/e98ea33388196bfe30c7a69e2abd5a93a8a701f8/straight.el#L2820

Instead, I hardcoded the recipe with EMACS=emacs which is sufficient for me and it no longer rebuilds unnecessarily

(straight-use-package
 `(org
   :type git
   :repo "https://code.orgmode.org/bzg/org-mode.git"
   :depth full
   :build (:not autoloads)
   :local-repo "org"
   :pre-build ,(list
                (concat (when (eq system-type 'berkeley-unix) "g")
                        "make")
                "autoloads"
                "EMACS=emacs")
   :files (:defaults "lisp/*.el"
                     "contrib/lisp/*.el")))

@raxod502
Copy link
Member

Maybe those variables should be evaluated at build time, rather than at recipe expansion time? I can't think of a good reason we'd want to rebuild Org just because a different path to Emacs is used. Perhaps if it's a different Emacs version, but in that case the build cache will be invalidated anyway.

@progfolio
Copy link
Contributor

Agreed. I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug build system external command org-mode
Milestone
No milestone
Development

No branches or pull requests
7 participants
@aaronjensen @aspiers @rileyrg @raxod502 @kevinjfoley @jdek @progfolio