[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orgmode] Re: org-install.el in Emacs probably should be removed
From: |
Tim O'Callaghan |
Subject: |
[Orgmode] Re: org-install.el in Emacs probably should be removed |
Date: |
Tue, 24 Feb 2009 16:38:00 +0100 |
On 16/02/2009, Bernt Hansen <address@hidden> wrote:
> Carsten Dominik <address@hidden> writes:
>
> > On Feb 15, 2009, at 11:18 PM, Tim O'Callaghan wrote:
> >
>
> >> The usage of org-install has the pre-requisite of having to compile
> >> the org.el files. This is no use to people like myself, who want to
> >> use the same .el files in XEmacs and Emacs due to incompatible .elc
> >> problems. Its also no use to people who do no have a build system or
> >> make binary installed e.g. windows users, locked down linux/unix
> >> systems etc.
> >>
> >> How about adding a skeleton org-install.el that gets overwritten by
> >> the make?
> >
> > org-install.el is part of the distribution tar and zip files.
> > I cannot include it into the git repo because the git people tell
> > me that it is a bad idea to keep a product file under git
> > control (Bernt?).
>
>
> The main reason this is a bad idea in git master branch is that the file
> gets automatic changes on different systems and looks modified after
> each time you run make. This file gets in the way of other (real)
> changes since git thinks the working tree is dirty and prevents changing
> branches, rebasing, or merging with a dirty tree. The contents of the
> org-install.el file are uninteresting and really does not belong in the
> tracked files for the project since it is a product of the build
> procedure.
>
> If you want a skeleton org-install.el in the tar/zip files then you
> probably should generate that when producing the tar/zip files.
>
>
> -Bernt
>
That is a fair point, its usually counter productive to put a build
product under revision control.
So for the sake of those looking for an example one, you'll find a
generated example attached, for V6.23b
I wonder if it is possible to implement a mechanism to check the
'freshness' of the org-install? say embedding the org-version number
it was created with, and org checking to see if it is compatible, or
needs updating?
Tim.
example-org-install.el
Description: application/emacs-lisp