Hi all, tl;dr I've seemingly managed to install org 7.9, but M-x org-version yields Org-mode version N/A (N/A @ /home/brian/.emacsd/site-lisp/) The details: I've not really been following the new build system discussions, but was half-ways dreading my first org-mode upgrade unde them :-) I just downloaded the gz.tar of the newly released 7.9; it untarred to org-7.9-3-ga986d3. I did my best to follow the instruction on <http://orgmode.org/manual/Installation.html> and in local.mk. I made the changes: # Where local software is found # Note, *not* ~/.emacs.d but ~/.emacsd, a dir I created to store my personal emacs stuff prefix = /home/brian/.emacsd # Where local lisp files go. lispdir= $(prefix)/site-lisp # Where local data files go. datadir = $(prefix)/etc # Where info files go. infodir = $(prefix)/info ORG_MAKE_DOC = info # html pdf INSTALL_INFO = ginstall-info # Debian: avoid harmless warning message (Apart from the ORG_MAKE_DOC setting, these are exactly the changes I have always made to upgrade from one released version to another. I've tried multiple times both with and without the ORG_MAKE_DOC and INSTALL_INFO settings.) I then ran make help, make config, and make install as instructed. (After the issue described below, I also deleted everything installed and tried again with sudo make install achieving the same result.) Once that was done, I launched a fresh emacs, visited an .org file, and ran M-x org-version. What I got was: Org-mode version N/A (N/A @ /home/brian/.emacsd/site-lisp/) This seems to indicate that something went wrong, somewhere. I'm pretty sure at least some of org 7.9 got installed. On the newly installed version, I have org-insert-all-links available (via M-x org-insert-all<TAB>) whereas on the previously installed version of org-mode, tab completion for this command name does not work. M-x emacs-version yields: GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2010-12-11 on brahms, modified by Debian ~$ make --version GNU Make 3.81 The first things I have in my .emacs that are org-related are adding /home/brian/.emacsd/site-lisp to my load path and then (require 'org-install). I've little doubt it is operator error, but I am at a loss for how to proceed. Little help? Thanks and best, Brian vdB
Brian van den Broek writes: > I've seemingly managed to install org 7.9, but M-x org-version yields > Org-mode version N/A (N/A @ /home/brian/.emacsd/site-lisp/) > > The details: You could've saved yourself a lot of writing if you'd just posted what make config-all prints out. But the only way this output from org-verison can be produced by a compiled version of Org is if you install with make, but without Git (like you later tell us you've done). In this case, you need to tell make the version you're installing since it cannot ask Git for it: make ORGVERSION=7.9 GITVERSION=org-7.9-3-ga986d3 install Rest assured that aside from two missing version strings everything has worked likee it should as far as I can tell. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
On 25 August 2012 13:24, Achim Gratz <Stromeko@nexgo.de> wrote: > Brian van den Broek writes: >> I've seemingly managed to install org 7.9, but M-x org-version yields >> Org-mode version N/A (N/A @ /home/brian/.emacsd/site-lisp/) >> >> The details: > > You could've saved yourself a lot of writing if you'd just posted what > > make config-all > > prints out. But the only way this output from org-verison can be > produced by a compiled version of Org is if you install with make, but > without Git (like you later tell us you've done). In this case, you > need to tell make the version you're installing since it cannot ask Git > for it: > > make ORGVERSION=7.9 GITVERSION=org-7.9-3-ga986d3 install > Thanks Achim. That does seem to fix the manifested problem. (make install-info seems to leave with with the 6.33x docs, but that's a problem for another day and thread, I expect.) Sorry for the verbosity. As I expect is clear, I don't have a good handle on what is going on and opted for risking too much information to avoid the need to tease more out of me through a few rounds of responses. I would suggest that the installation instructions at <http://orgmode.org/manual/Installation.html#Installation> be updated, as there one finds nothing about the need for ORGVERSION and GITVERTSION arguments to make. (While I know patches are welcome, I am reluctant to try to patch docs for an issue that I don't understand well.) Thanks and best, Brian vdB
Brian van den Broek writes: > On 25 August 2012 13:24, Achim Gratz <Stromeko@nexgo.de> wrote: > That does seem to fix the manifested problem. (make install-info seems > to leave with with the 6.33x docs, but that's a problem for another > day and thread, I expect.) Then the configuration for the info directory is wrong (you install into a different directory than what Emacs uses to find it). Check where Emacs picks up the old documentation and change the configuration so that the new info file goes where the old was. If you have multiple info directories set up, check that your place of installation comes first. > Sorry for the verbosity. No need to be sorry, I didn't mean to say you wrote too much… just that you could have saved yourself some time that way. > I would suggest that the installation instructions at > <http://orgmode.org/manual/Installation.html#Installation> be updated, > as there one finds nothing about the need for ORGVERSION and > GITVERSION arguments to make. I hadn't really considered installation from tarballs down to that detail. I may just add some code to recognize that situation and put the version information into the tarball itself. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Achim Gratz <Stromeko@nexgo.de> writes:
>> I would suggest that the installation instructions at
>> <http://orgmode.org/manual/Installation.html#Installation> be updated,
>> as there one finds nothing about the need for ORGVERSION and
>> GITVERSION arguments to make.
>
> I hadn't really considered installation from tarballs down to that
> detail. I may just add some code to recognize that situation and put
> the version information into the tarball itself.
There is something I don't understand here: the version *is* in
org-7.9.tar.gz and org-7.9.zip with lisp/org-version.el.
I assumed that, in the absence of git, `make' would rely on this.
True?
--
Bastien
On 25 August 2012 16:12, Bastien <bzg@altern.org> wrote:
> Achim Gratz <Stromeko@nexgo.de> writes:
>
>>> I would suggest that the installation instructions at
>>> <http://orgmode.org/manual/Installation.html#Installation> be updated,
>>> as there one finds nothing about the need for ORGVERSION and
>>> GITVERSION arguments to make.
>>
>> I hadn't really considered installation from tarballs down to that
>> detail. I may just add some code to recognize that situation and put
>> the version information into the tarball itself.
>
> There is something I don't understand here: the version *is* in
> org-7.9.tar.gz and org-7.9.zip with lisp/org-version.el.
>
> I assumed that, in the absence of git, `make' would rely on this.
>
> True?
>
> --
> Bastien
Hi Bastien,
I don't warrant that all else is in order on my system, but for me, it did not.
Best,
Brian
Bastien writes: > There is something I don't understand here: the version *is* in > org-7.9.tar.gz and org-7.9.zip with lisp/org-version.el. Yes, that is for when you would want to run uncompiled from the unpacked tarball. > I assumed that, in the absence of git, `make' would rely on this. No. Make always re-makes these targets and in the absence of getting a version from git or from configuration it falls back to "N/A". I'll add a file to the tarball that just defines these two variables and include that when absolutely no version is defined. If these variables are still undefined I continue to fall back to "N/A". The version from a tarball can't change, so it's OK to fix it like that I think. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Achim Gratz <Stromeko@nexgo.de> writes: > Bastien writes: >> There is something I don't understand here: the version *is* in >> org-7.9.tar.gz and org-7.9.zip with lisp/org-version.el. > > Yes, that is for when you would want to run uncompiled from the unpacked > tarball. Okay. > I'll add > a file to the tarball that just defines these two variables and include > that when absolutely no version is defined. Can't we just have this in default.mk? Do we need yet another file? > If these variables are > still undefined I continue to fall back to "N/A". The version from a > tarball can't change, so it's OK to fix it like that I think. Okay. Thanks, -- Bastien
Bastien writes: >> I'll add >> a file to the tarball that just defines these two variables and include >> that when absolutely no version is defined. > > Can't we just have this in default.mk? Do we need yet another file? That would mean I'd have to change default.mk while building the tarball and then change it back afterwards. There's no way I can make that completely foolproof, so I'll rather just generate a file specifically for the tarball that I can throw away any time without having to keep state. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Achim Gratz <Stromeko@nexgo.de> writes:
> Bastien writes:
>>> I'll add
>>> a file to the tarball that just defines these two variables and include
>>> that when absolutely no version is defined.
>>
>> Can't we just have this in default.mk? Do we need yet another file?
>
> That would mean I'd have to change default.mk while building the tarball
> and then change it back afterwards. There's no way I can make that
> completely foolproof, so I'll rather just generate a file specifically
> for the tarball that I can throw away any time without having to keep
> state.
Let me know if I understand correctly: that's because you don't want
default.mk to contain a manually inserted ORGVERSION variable, right?
Otherwise I don't see the problem with having a fallback ORGVERSION
variable in default.mk (which I'll happily insert manually, to have a
taste of the Good Old Days, when (defconst org-version "...") was
still in org.el... :)
--
Bastien