On 16/02/2009, Bernt Hansen wrote: > Carsten Dominik 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.