emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: emacs-orgmode@gnu.org
Subject: Re: mixed orgmode installation
Date: Sun, 08 Sep 2013 20:39:54 +0200	[thread overview]
Message-ID: <87wqmr5f9h.fsf@Rainer.invalid> (raw)
In-Reply-To: CA+M2ft8GpEj98R_7OfjY2QxE_L0j8h6eMOctyJn=LKrQZv+-KA@mail.gmail.com

John Hendy writes:
> I'm with you so far. But if all of Org lives in /path/to/org.git/lisp,
> what's to go wrong if it's there vs. /system/path/site-lisp?

It is only "there" when you've built Org and whenever you do something
in Git, it's "gone", only that you might not see that.  Having Org
installed in some other place decouples it from what you do in the work
tree.  That makes it less likely that you load up an Emacs session, do
something in Org, then do something in Git and then go back to sour
Emacs session and load some other parts of Org that won't fit with the
version you've started with.

> I'm not sure I follow this one. Does `make up2` look for changed paths
> (contrib/lisp vs lisp/) since the last `make up2` ? If not, how would
> I know to do `make clean-install` vs. just `make install`?

You should know if you changed something, I suppose.

> I'm talking about your original comment that running out of a git repo
> can lead to:
> - it being just to easy to mess up with the autoloads

Yes, if you forget to re-make them after a change to the source code.

> - have stale byte-compiled files I forgot about somewhere

Yes, because Emacs prefers the byte-compiled files over the sources,
even when it knows the sources are newer.  So when you update from Git,
but don't byte-compile, you will load an older version of Org rather
than the one you think you are using.  If you are running from a Git
tree, you should always keep Org uncompiled for this reason (that's why
that make target exists).

> P.S. And yes, I derailed from the mixed install case due to your
> comment as I thought it was worth looking into. I'm doing what you
> advise against and I wanted to know the risks and more details about
> what I might run into.

You can do whatever you want as long as you can deal with the resulting
problems.  Depending on how careful you are you may never encounter one,
but the most frequent reasons for mixed installs are forgetting to
generate the autoload files or using an init sequence that loads Org
from two different places.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:

      reply	other threads:[~2013-09-08 18:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-04 13:52 mixed orgmode installation Johannes Rainer
2013-09-04 14:19 ` Thorsten Jolitz
2013-09-04 14:52   ` Johannes Rainer
2013-09-04 15:07     ` Suvayu Ali
2013-09-08  5:40       ` adam
2013-09-08 14:37         ` John Hendy
2013-09-08 15:10           ` Suvayu Ali
2013-09-08 15:26             ` John Hendy
2013-09-08 16:52               ` Achim Gratz
2014-01-02  8:06                 ` Justin Gordon
2014-01-03  8:43                   ` Sharon Kimble
2014-01-03 18:08                     ` Justin Gordon
2014-01-03 18:49                   ` John Hendy
2013-09-04 19:20 ` Achim Gratz
2013-09-08 14:31   ` John Hendy
2013-09-08 16:41     ` Achim Gratz
2013-09-08 17:52       ` John Hendy
2013-09-08 18:39         ` Achim Gratz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wqmr5f9h.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=emacs-orgmode@gnu.org \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).