Precompiled Emacs

Precompiled Emacs

[Johan Andersson]

Hi,

I want to create a precompiled Emacs installation that will work on
Gnu/Linux systems. I could use your help because of my limited knowledge
about compilation.

First off, it seems that I want to build this Emacs on an amd64
architecture? From what I understand it is backwards compatible with x86,
hence will cover most systems.

I tried it out and when I moved the build to another system, I got the
error that libtiff5.so was not found. So I guess I can build with the
option "--without-tiff". But I guess this is only one of few of these
issues I will run into...

How do I best go about this to make it work on most systems?

Thanks!

Re: Precompiled Emacs

[Carson Chittom]

Johan Andersson <johan.rejeep@gmail.com> writes:

> I want to create a precompiled Emacs installation that will work on
> Gnu/Linux systems. I could use your help because of my limited knowledge
> about compilation.

With what aim?  Most Linux distributions already contain an Emacs
binary which can be installed through the distributions' normal package
system(s).  

Re: Precompiled Emacs

[Peter Dyballa]

Am 03.11.2013 um 12:56 schrieb Johan Andersson:

> First off, it seems that I want to build this Emacs on an amd64
> architecture? From what I understand it is backwards compatible with x86,
> hence will cover most systems.

The name "amd64" is obviously based on 64-bit wide words. The "x86" architecture was supporting 8-bit systems. So I would assume that an x86 application could possibly run on an amd64 system, not otherwise.

> 
> I tried it out and when I moved the build to another system, I got the
> error that libtiff5.so was not found. So I guess I can build with the
> option "--without-tiff". But I guess this is only one of few of these
> issues I will run into…

You have two more options: ImageMagick and static libraries.

> 
> How do I best go about this to make it work on most systems?

Make it a complete virtual system, something like those system images you can download from VMware. That way you don't have to make any assumptions of the target platforms, all is included, even the batteries.

--
Greetings

  Pete

Life is the only flaw in an otherwise perfect nonexistence
				– Schopenhauer

Re: Precompiled Emacs

[Jambunathan K]

Johan Andersson <johan.rejeep@gmail.com> writes:

> Hi,
>
> I want to create a precompiled Emacs installation that will work on
> Gnu/Linux systems. I could use your help because of my limited knowledge
> about compilation.
>
> First off, it seems that I want to build this Emacs on an amd64
> architecture? From what I understand it is backwards compatible with x86,
> hence will cover most systems.
>
> I tried it out and when I moved the build to another system, I got the
> error that libtiff5.so was not found. So I guess I can build with the
> option "--without-tiff". But I guess this is only one of few of these
> issues I will run into...
>
> How do I best go about this to make it work on most systems?


 Download the source code of development version:

   http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz

Or a stable version

   ftp://ftp.gnu.org/gnu/emacs/

If you are on a Debian, the following the following two commands will
install all the libraries that were used to build Emacs.

  apt-get install build-essential
  apt-get build-dep emacs

Go ahead and compile the tarball.  Follow the instructions in
INSTALL.BZR for development version and README(or whatever) in the
stable tarball.

Now you will get an Emacs which has same set of capabilities as the
original build.

Now if you want to add to or remove from default set of features then
you have to configure your Emacs differently.


> Thanks!

Re: Precompiled Emacs

[Johan Andersson]

I've read the instructions in INSTALL, which are very good. I tried and did
a build with:

$ ./configure --prefix emacs-install --without-all --without-x
$ make boostrap
$ make install

The installation works just fine on the system it was built on, but when I
move that installation to another machine, I get messages such as:

Warning: arch-dependent data dir
(/home/rejeep/emacs-install/libexec/emacs/24.3/x86_64-unknown-linux-gnu/)
does not exist.
Warning: arch-independent data dir
(/home/rejeep/emacs-install/share/emacs/24.3/etc/) does not exist.
Warning: Lisp directory `/home/rejeep/emacs-install/share/emacs/24.3/lisp'
does not exist.
Warning: Lisp directory `/home/rejeep/emacs-install/share/emacs/24.3/leim'
does not exist.
Error: charsets directory not found:
/home/rejeep/emacs-install/share/emacs/24.3/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!


On Sun, Nov 3, 2013 at 8:56 PM, Jambunathan K <kjambunathan@gmail.com>wrote:

> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> > Hi,
> >
> > I want to create a precompiled Emacs installation that will work on
> > Gnu/Linux systems. I could use your help because of my limited knowledge
> > about compilation.
> >
> > First off, it seems that I want to build this Emacs on an amd64
> > architecture? From what I understand it is backwards compatible with x86,
> > hence will cover most systems.
> >
> > I tried it out and when I moved the build to another system, I got the
> > error that libtiff5.so was not found. So I guess I can build with the
> > option "--without-tiff". But I guess this is only one of few of these
> > issues I will run into...
> >
> > How do I best go about this to make it work on most systems?
>
>
>  Download the source code of development version:
>
>    http://git.savannah.gnu.org/cgit/emacs.git/snapshot/emacs-master.tar.gz
>
> Or a stable version
>
>    ftp://ftp.gnu.org/gnu/emacs/
>
> If you are on a Debian, the following the following two commands will
> install all the libraries that were used to build Emacs.
>
>   apt-get install build-essential
>   apt-get build-dep emacs
>
> Go ahead and compile the tarball.  Follow the instructions in
> INSTALL.BZR for development version and README(or whatever) in the
> stable tarball.
>
> Now you will get an Emacs which has same set of capabilities as the
> original build.
>
> Now if you want to add to or remove from default set of features then
> you have to configure your Emacs differently.
>
>
> > Thanks!
>

Re: Precompiled Emacs

[Dan Espen]

Johan Andersson <johan.rejeep@gmail.com> writes:

> I've read the instructions in INSTALL, which are very good. I tried and did
> a build with:
>
> $ ./configure --prefix emacs-install --without-all --without-x

That prefix is not doing what you think it is.

> $ make boostrap
> $ make install
>
> The installation works just fine on the system it was built on, but when I
> move that installation to another machine, I get messages such as:
>
> Warning: arch-dependent data dir
> (/home/rejeep/emacs-install/libexec/emacs/24.3/x86_64-unknown-linux-gnu/)
> does not exist.
...

As you can see, you told configure your prefix was emacs-install
but emacs considers the prefix to be the full path.  This is consistent
with most other software.  The real prefix is 
/home/rejeep/emacs-install.

You should really explain what you are trying to do because you are way
off base with your approach.

-- 
Dan Espen

Re: Precompiled Emacs

[Kai Großjohann]

Johan Andersson wrote:
> I've read the instructions in INSTALL, which are very good. I tried and did
> a build with:
> 
> $ ./configure --prefix emacs-install --without-all --without-x

The assumption is that the argument of --prefix is the fully qualified
directory name where Emacs is installed.  If you omit --prefix, it will
use /usr/local.

Conventionally, people are expected to use values such as
/usr/local/emacs or /opt/emacs or something.

Kai

Re: Precompiled Emacs

[Johan Andersson]

Well, the thing is that I don't want to install it there. I guess it's not
possible to compile Emacs, archive it, move to another machine and there
"make install" to the desired prefix?

The purpose of this is to allow for fast installations and at the same time
allow for multiple Emacs version. So that will not work with
"/usr/local/emacs".

I guess I could do:

$ ./configure --prefix /usr/local/emacs-x.y.z --without-all --without-x
$ make bootstrap
$ tar ...

... move to another system

$ make install

That would mean a larger tar-file. But I guess I could "make install" on
the compile system and then tar "/usr/local/emacs-x.y.z".

Still... seems a bit weird that this limitation exists. Maybe there's a
good reason for it?


On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <kai.grossjohann@gmx.net>wrote:

> Johan Andersson wrote:
> > I've read the instructions in INSTALL, which are very good. I tried and
> did
> > a build with:
> >
> > $ ./configure --prefix emacs-install --without-all --without-x
>
> The assumption is that the argument of --prefix is the fully qualified
> directory name where Emacs is installed.  If you omit --prefix, it will
> use /usr/local.
>
> Conventionally, people are expected to use values such as
> /usr/local/emacs or /opt/emacs or something.
>
> Kai
>
>

Re: Precompiled Emacs

[Jambunathan K]

You don't say what distribution you are working with.  Why not mess
around with the distributed deb-srcs and make a custom .deb out of it.

As you see below, you can choose one among the many different
alternatives for emacs.

kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
   5792 Dec 11  2010 b2m.emacs23
  82760 Dec 11  2010 ctags.emacs23
   3309 Aug  7  2010 dh_installemacsen
  34780 Dec 11  2010 ebrowse.emacs23
     23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
      9 Aug 18 15:54 emacs23 -> emacs23-x
6583560 Dec 11  2010 emacs23-x
     29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
  16816 Dec 11  2010 emacsclient.emacs23
  81064 Dec 11  2010 etags.emacs23
   7294 Dec 11  2010 grep-changelog.emacs23
   3983 Dec 11  2010 rcs-checkin.emacs23


Johan Andersson <johan.rejeep@gmail.com> writes:

> Well, the thing is that I don't want to install it there. I guess it's not
> possible to compile Emacs, archive it, move to another machine and there
> "make install" to the desired prefix?
>
> The purpose of this is to allow for fast installations and at the same time
> allow for multiple Emacs version. So that will not work with
> "/usr/local/emacs".
>
> I guess I could do:
>
> $ ./configure --prefix /usr/local/emacs-x.y.z --without-all --without-x
> $ make bootstrap
> $ tar ...
>
> ... move to another system
>
> $ make install
>
> That would mean a larger tar-file. But I guess I could "make install" on
> the compile system and then tar "/usr/local/emacs-x.y.z".
>
> Still... seems a bit weird that this limitation exists. Maybe there's a
> good reason for it?
>
>
> On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <kai.grossjohann@gmx.net>wrote:
>
>> Johan Andersson wrote:
>> > I've read the instructions in INSTALL, which are very good. I tried and
>> did
>> > a build with:
>> >
>> > $ ./configure --prefix emacs-install --without-all --without-x
>>
>> The assumption is that the argument of --prefix is the fully qualified
>> directory name where Emacs is installed.  If you omit --prefix, it will
>> use /usr/local.
>>
>> Conventionally, people are expected to use values such as
>> /usr/local/emacs or /opt/emacs or something.
>>
>> Kai
>>
>>

Re: Precompiled Emacs

[Johan Andersson]

> You don't say what distribution you are working with.

Any, that's the idea.


On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <kjambunathan@gmail.com>wrote:

>
> You don't say what distribution you are working with.  Why not mess
> around with the distributed deb-srcs and make a custom .deb out of it.
>
> As you see below, you can choose one among the many different
> alternatives for emacs.
>
> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
>    5792 Dec 11  2010 b2m.emacs23
>   82760 Dec 11  2010 ctags.emacs23
>    3309 Aug  7  2010 dh_installemacsen
>   34780 Dec 11  2010 ebrowse.emacs23
>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
>       9 Aug 18 15:54 emacs23 -> emacs23-x
> 6583560 Dec 11  2010 emacs23-x
>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
>   16816 Dec 11  2010 emacsclient.emacs23
>   81064 Dec 11  2010 etags.emacs23
>    7294 Dec 11  2010 grep-changelog.emacs23
>    3983 Dec 11  2010 rcs-checkin.emacs23
>
>
> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> > Well, the thing is that I don't want to install it there. I guess it's
> not
> > possible to compile Emacs, archive it, move to another machine and there
> > "make install" to the desired prefix?
> >
> > The purpose of this is to allow for fast installations and at the same
> time
> > allow for multiple Emacs version. So that will not work with
> > "/usr/local/emacs".
> >
> > I guess I could do:
> >
> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all --without-x
> > $ make bootstrap
> > $ tar ...
> >
> > ... move to another system
> >
> > $ make install
> >
> > That would mean a larger tar-file. But I guess I could "make install" on
> > the compile system and then tar "/usr/local/emacs-x.y.z".
> >
> > Still... seems a bit weird that this limitation exists. Maybe there's a
> > good reason for it?
> >
> >
> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <kai.grossjohann@gmx.net
> >wrote:
> >
> >> Johan Andersson wrote:
> >> > I've read the instructions in INSTALL, which are very good. I tried
> and
> >> did
> >> > a build with:
> >> >
> >> > $ ./configure --prefix emacs-install --without-all --without-x
> >>
> >> The assumption is that the argument of --prefix is the fully qualified
> >> directory name where Emacs is installed.  If you omit --prefix, it will
> >> use /usr/local.
> >>
> >> Conventionally, people are expected to use values such as
> >> /usr/local/emacs or /opt/emacs or something.
> >>
> >> Kai
> >>
> >>
>

Re: Precompiled Emacs

[Phillip Lord]

But you don't say why!

If you want to build a prebuilt binary which will install in a sane way,
then building something for the appropriate package management system
seems the sensible way. Your only stated aim (fast installations,
multiple versions) is fulfilled with this solution.

But, emacs packages already exist for most distributions. So using one
of these makes most sense. Unless you want to extend and modify emacs in
some way; but if you want to do this, then, probably package.el will be
enough.

Phil




Johan Andersson <johan.rejeep@gmail.com> writes:

>> You don't say what distribution you are working with.
>
> Any, that's the idea.
>
>
> On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <kjambunathan@gmail.com>wrote:
>
>>
>> You don't say what distribution you are working with.  Why not mess
>> around with the distributed deb-srcs and make a custom .deb out of it.
>>
>> As you see below, you can choose one among the many different
>> alternatives for emacs.
>>
>> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
>>    5792 Dec 11  2010 b2m.emacs23
>>   82760 Dec 11  2010 ctags.emacs23
>>    3309 Aug  7  2010 dh_installemacsen
>>   34780 Dec 11  2010 ebrowse.emacs23
>>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
>>       9 Aug 18 15:54 emacs23 -> emacs23-x
>> 6583560 Dec 11  2010 emacs23-x
>>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
>>   16816 Dec 11  2010 emacsclient.emacs23
>>   81064 Dec 11  2010 etags.emacs23
>>    7294 Dec 11  2010 grep-changelog.emacs23
>>    3983 Dec 11  2010 rcs-checkin.emacs23
>>
>>
>> Johan Andersson <johan.rejeep@gmail.com> writes:
>>
>> > Well, the thing is that I don't want to install it there. I guess it's
>> not
>> > possible to compile Emacs, archive it, move to another machine and there
>> > "make install" to the desired prefix?
>> >
>> > The purpose of this is to allow for fast installations and at the same
>> time
>> > allow for multiple Emacs version. So that will not work with
>> > "/usr/local/emacs".
>> >
>> > I guess I could do:
>> >
>> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all --without-x
>> > $ make bootstrap
>> > $ tar ...
>> >
>> > ... move to another system
>> >
>> > $ make install
>> >
>> > That would mean a larger tar-file. But I guess I could "make install" on
>> > the compile system and then tar "/usr/local/emacs-x.y.z".
>> >
>> > Still... seems a bit weird that this limitation exists. Maybe there's a
>> > good reason for it?
>> >
>> >
>> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <kai.grossjohann@gmx.net
>> >wrote:
>> >
>> >> Johan Andersson wrote:
>> >> > I've read the instructions in INSTALL, which are very good. I tried
>> and
>> >> did
>> >> > a build with:
>> >> >
>> >> > $ ./configure --prefix emacs-install --without-all --without-x
>> >>
>> >> The assumption is that the argument of --prefix is the fully qualified
>> >> directory name where Emacs is installed.  If you omit --prefix, it will
>> >> use /usr/local.
>> >>
>> >> Conventionally, people are expected to use values such as
>> >> /usr/local/emacs or /opt/emacs or something.
>> >>
>> >> Kai
>> >>
>> >>
>>
>
>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: Precompiled Emacs

[Johan Andersson]

I don't want to use a package manager, because they do not support enough
versions and there is usually no way of switching between different
versions.


On Mon, Nov 4, 2013 at 12:46 PM, Phillip Lord
<phillip.lord@newcastle.ac.uk>wrote:

>
> But you don't say why!
>
> If you want to build a prebuilt binary which will install in a sane way,
> then building something for the appropriate package management system
> seems the sensible way. Your only stated aim (fast installations,
> multiple versions) is fulfilled with this solution.
>
> But, emacs packages already exist for most distributions. So using one
> of these makes most sense. Unless you want to extend and modify emacs in
> some way; but if you want to do this, then, probably package.el will be
> enough.
>
> Phil
>
>
>
>
> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> >> You don't say what distribution you are working with.
> >
> > Any, that's the idea.
> >
> >
> > On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <kjambunathan@gmail.com
> >wrote:
> >
> >>
> >> You don't say what distribution you are working with.  Why not mess
> >> around with the distributed deb-srcs and make a custom .deb out of it.
> >>
> >> As you see below, you can choose one among the many different
> >> alternatives for emacs.
> >>
> >> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
> >>    5792 Dec 11  2010 b2m.emacs23
> >>   82760 Dec 11  2010 ctags.emacs23
> >>    3309 Aug  7  2010 dh_installemacsen
> >>   34780 Dec 11  2010 ebrowse.emacs23
> >>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
> >>       9 Aug 18 15:54 emacs23 -> emacs23-x
> >> 6583560 Dec 11  2010 emacs23-x
> >>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
> >>   16816 Dec 11  2010 emacsclient.emacs23
> >>   81064 Dec 11  2010 etags.emacs23
> >>    7294 Dec 11  2010 grep-changelog.emacs23
> >>    3983 Dec 11  2010 rcs-checkin.emacs23
> >>
> >>
> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >>
> >> > Well, the thing is that I don't want to install it there. I guess it's
> >> not
> >> > possible to compile Emacs, archive it, move to another machine and
> there
> >> > "make install" to the desired prefix?
> >> >
> >> > The purpose of this is to allow for fast installations and at the same
> >> time
> >> > allow for multiple Emacs version. So that will not work with
> >> > "/usr/local/emacs".
> >> >
> >> > I guess I could do:
> >> >
> >> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all
> --without-x
> >> > $ make bootstrap
> >> > $ tar ...
> >> >
> >> > ... move to another system
> >> >
> >> > $ make install
> >> >
> >> > That would mean a larger tar-file. But I guess I could "make install"
> on
> >> > the compile system and then tar "/usr/local/emacs-x.y.z".
> >> >
> >> > Still... seems a bit weird that this limitation exists. Maybe there's
> a
> >> > good reason for it?
> >> >
> >> >
> >> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <
> kai.grossjohann@gmx.net
> >> >wrote:
> >> >
> >> >> Johan Andersson wrote:
> >> >> > I've read the instructions in INSTALL, which are very good. I tried
> >> and
> >> >> did
> >> >> > a build with:
> >> >> >
> >> >> > $ ./configure --prefix emacs-install --without-all --without-x
> >> >>
> >> >> The assumption is that the argument of --prefix is the fully
> qualified
> >> >> directory name where Emacs is installed.  If you omit --prefix, it
> will
> >> >> use /usr/local.
> >> >>
> >> >> Conventionally, people are expected to use values such as
> >> >> /usr/local/emacs or /opt/emacs or something.
> >> >>
> >> >> Kai
> >> >>
> >> >>
> >>
> >
> >
>
> --
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics,             Email:
> phillip.lord@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,               skype: russet_apples
> Newcastle University,                   twitter: phillord
> NE1 7RU
>

Re: Precompiled Emacs

[Phillip Lord]

Well, I have both emacs23 and emacs24 installed on my machine. And there
is alternatives support. But still this is all black-box guess work.
Instead of saying what you do not way to do, can you explain what you
are trying to achieve in the first place? So far I have got:

1) You want to install Emacs on different linux distros
2) You want to use a precompiled distribution for speed of installation
3) You want to be able to use different versions
4) You want to have it work on any distribution

My own feeling is that 1-3 can be done with a package manager and that
4 can't be done with anything, but that is irrelevant as someone has
already done it for almost all distros.

If you can describe what you exact use case is, then you would probably
get better advice.

Phil


Johan Andersson <johan.rejeep@gmail.com> writes:

> I don't want to use a package manager, because they do not support enough
> versions and there is usually no way of switching between different
> versions.
>
>
> On Mon, Nov 4, 2013 at 12:46 PM, Phillip Lord
> <phillip.lord@newcastle.ac.uk>wrote:
>
>>
>> But you don't say why!
>>
>> If you want to build a prebuilt binary which will install in a sane way,
>> then building something for the appropriate package management system
>> seems the sensible way. Your only stated aim (fast installations,
>> multiple versions) is fulfilled with this solution.
>>
>> But, emacs packages already exist for most distributions. So using one
>> of these makes most sense. Unless you want to extend and modify emacs in
>> some way; but if you want to do this, then, probably package.el will be
>> enough.
>>
>> Phil
>>
>>
>>
>>
>> Johan Andersson <johan.rejeep@gmail.com> writes:
>>
>> >> You don't say what distribution you are working with.
>> >
>> > Any, that's the idea.
>> >
>> >
>> > On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <kjambunathan@gmail.com
>> >wrote:
>> >
>> >>
>> >> You don't say what distribution you are working with.  Why not mess
>> >> around with the distributed deb-srcs and make a custom .deb out of it.
>> >>
>> >> As you see below, you can choose one among the many different
>> >> alternatives for emacs.
>> >>
>> >> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
>> >>    5792 Dec 11  2010 b2m.emacs23
>> >>   82760 Dec 11  2010 ctags.emacs23
>> >>    3309 Aug  7  2010 dh_installemacsen
>> >>   34780 Dec 11  2010 ebrowse.emacs23
>> >>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
>> >>       9 Aug 18 15:54 emacs23 -> emacs23-x
>> >> 6583560 Dec 11  2010 emacs23-x
>> >>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
>> >>   16816 Dec 11  2010 emacsclient.emacs23
>> >>   81064 Dec 11  2010 etags.emacs23
>> >>    7294 Dec 11  2010 grep-changelog.emacs23
>> >>    3983 Dec 11  2010 rcs-checkin.emacs23
>> >>
>> >>
>> >> Johan Andersson <johan.rejeep@gmail.com> writes:
>> >>
>> >> > Well, the thing is that I don't want to install it there. I guess it's
>> >> not
>> >> > possible to compile Emacs, archive it, move to another machine and
>> there
>> >> > "make install" to the desired prefix?
>> >> >
>> >> > The purpose of this is to allow for fast installations and at the same
>> >> time
>> >> > allow for multiple Emacs version. So that will not work with
>> >> > "/usr/local/emacs".
>> >> >
>> >> > I guess I could do:
>> >> >
>> >> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all
>> --without-x
>> >> > $ make bootstrap
>> >> > $ tar ...
>> >> >
>> >> > ... move to another system
>> >> >
>> >> > $ make install
>> >> >
>> >> > That would mean a larger tar-file. But I guess I could "make install"
>> on
>> >> > the compile system and then tar "/usr/local/emacs-x.y.z".
>> >> >
>> >> > Still... seems a bit weird that this limitation exists. Maybe there's
>> a
>> >> > good reason for it?
>> >> >
>> >> >
>> >> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <
>> kai.grossjohann@gmx.net
>> >> >wrote:
>> >> >
>> >> >> Johan Andersson wrote:
>> >> >> > I've read the instructions in INSTALL, which are very good. I tried
>> >> and
>> >> >> did
>> >> >> > a build with:
>> >> >> >
>> >> >> > $ ./configure --prefix emacs-install --without-all --without-x
>> >> >>
>> >> >> The assumption is that the argument of --prefix is the fully
>> qualified
>> >> >> directory name where Emacs is installed.  If you omit --prefix, it
>> will
>> >> >> use /usr/local.
>> >> >>
>> >> >> Conventionally, people are expected to use values such as
>> >> >> /usr/local/emacs or /opt/emacs or something.
>> >> >>
>> >> >> Kai
>> >> >>
>> >> >>
>> >>
>> >
>> >
>>
>> --
>> Phillip Lord,                           Phone: +44 (0) 191 222 7827
>> Lecturer in Bioinformatics,             Email:
>> phillip.lord@newcastle.ac.uk
>> School of Computing Science,
>> http://homepages.cs.ncl.ac.uk/phillip.lord
>> Room 914 Claremont Tower,               skype: russet_apples
>> Newcastle University,                   twitter: phillord
>> NE1 7RU
>>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: Precompiled Emacs

[Johan Andersson]

Sure, sorry if I am unclear.

I have a project called EVM - Emacs Version Manager (
https://github.com/rejeep/evm). The idea with the project is that it should
be possible to install and easily switch between different Emacs version.
The primary (but not only) usage of this package is that Emacs developers
should be able to test their package against a lot of different versions.
Emacs-23 and Emacs-24 is not good enough. I just recently noticed that one
of my packages worked fine in 24.3, but not in 24.1 and 24.2.

EVM in its current state works fine, but you have to compile Emacs from
scratch. To allow for setting up this kind of testing on for example Travis
CI, I want to provide pre compiled binaries, because it takes too long time
to build Emacs from source.

Basically, I want to be able to do this:

for version in emacs-23.4*-bin* emacs-24.1*-bin* emacs-24.2*-bin* emacs-24.3
*-bin* emacs-git-trunk*-bin*; do
  evm install $version
  evm use $version
  cd /path/to/my/project
  make test
done

Hope this makes it a bit more clear of what I'm trying to achieve.


On Mon, Nov 4, 2013 at 2:21 PM, Phillip Lord
<phillip.lord@newcastle.ac.uk>wrote:

>
>
> Well, I have both emacs23 and emacs24 installed on my machine. And there
> is alternatives support. But still this is all black-box guess work.
> Instead of saying what you do not way to do, can you explain what you
> are trying to achieve in the first place? So far I have got:
>
> 1) You want to install Emacs on different linux distros
> 2) You want to use a precompiled distribution for speed of installation
> 3) You want to be able to use different versions
> 4) You want to have it work on any distribution
>
> My own feeling is that 1-3 can be done with a package manager and that
> 4 can't be done with anything, but that is irrelevant as someone has
> already done it for almost all distros.
>
> If you can describe what you exact use case is, then you would probably
> get better advice.
>
> Phil
>
>
> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> > I don't want to use a package manager, because they do not support enough
> > versions and there is usually no way of switching between different
> > versions.
> >
> >
> > On Mon, Nov 4, 2013 at 12:46 PM, Phillip Lord
> > <phillip.lord@newcastle.ac.uk>wrote:
> >
> >>
> >> But you don't say why!
> >>
> >> If you want to build a prebuilt binary which will install in a sane way,
> >> then building something for the appropriate package management system
> >> seems the sensible way. Your only stated aim (fast installations,
> >> multiple versions) is fulfilled with this solution.
> >>
> >> But, emacs packages already exist for most distributions. So using one
> >> of these makes most sense. Unless you want to extend and modify emacs in
> >> some way; but if you want to do this, then, probably package.el will be
> >> enough.
> >>
> >> Phil
> >>
> >>
> >>
> >>
> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >>
> >> >> You don't say what distribution you are working with.
> >> >
> >> > Any, that's the idea.
> >> >
> >> >
> >> > On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <kjambunathan@gmail.com
> >> >wrote:
> >> >
> >> >>
> >> >> You don't say what distribution you are working with.  Why not mess
> >> >> around with the distributed deb-srcs and make a custom .deb out of
> it.
> >> >>
> >> >> As you see below, you can choose one among the many different
> >> >> alternatives for emacs.
> >> >>
> >> >> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
> >> >>    5792 Dec 11  2010 b2m.emacs23
> >> >>   82760 Dec 11  2010 ctags.emacs23
> >> >>    3309 Aug  7  2010 dh_installemacsen
> >> >>   34780 Dec 11  2010 ebrowse.emacs23
> >> >>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
> >> >>       9 Aug 18 15:54 emacs23 -> emacs23-x
> >> >> 6583560 Dec 11  2010 emacs23-x
> >> >>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
> >> >>   16816 Dec 11  2010 emacsclient.emacs23
> >> >>   81064 Dec 11  2010 etags.emacs23
> >> >>    7294 Dec 11  2010 grep-changelog.emacs23
> >> >>    3983 Dec 11  2010 rcs-checkin.emacs23
> >> >>
> >> >>
> >> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >> >>
> >> >> > Well, the thing is that I don't want to install it there. I guess
> it's
> >> >> not
> >> >> > possible to compile Emacs, archive it, move to another machine and
> >> there
> >> >> > "make install" to the desired prefix?
> >> >> >
> >> >> > The purpose of this is to allow for fast installations and at the
> same
> >> >> time
> >> >> > allow for multiple Emacs version. So that will not work with
> >> >> > "/usr/local/emacs".
> >> >> >
> >> >> > I guess I could do:
> >> >> >
> >> >> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all
> >> --without-x
> >> >> > $ make bootstrap
> >> >> > $ tar ...
> >> >> >
> >> >> > ... move to another system
> >> >> >
> >> >> > $ make install
> >> >> >
> >> >> > That would mean a larger tar-file. But I guess I could "make
> install"
> >> on
> >> >> > the compile system and then tar "/usr/local/emacs-x.y.z".
> >> >> >
> >> >> > Still... seems a bit weird that this limitation exists. Maybe
> there's
> >> a
> >> >> > good reason for it?
> >> >> >
> >> >> >
> >> >> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <
> >> kai.grossjohann@gmx.net
> >> >> >wrote:
> >> >> >
> >> >> >> Johan Andersson wrote:
> >> >> >> > I've read the instructions in INSTALL, which are very good. I
> tried
> >> >> and
> >> >> >> did
> >> >> >> > a build with:
> >> >> >> >
> >> >> >> > $ ./configure --prefix emacs-install --without-all --without-x
> >> >> >>
> >> >> >> The assumption is that the argument of --prefix is the fully
> >> qualified
> >> >> >> directory name where Emacs is installed.  If you omit --prefix, it
> >> will
> >> >> >> use /usr/local.
> >> >> >>
> >> >> >> Conventionally, people are expected to use values such as
> >> >> >> /usr/local/emacs or /opt/emacs or something.
> >> >> >>
> >> >> >> Kai
> >> >> >>
> >> >> >>
> >> >>
> >> >
> >> >
> >>
> >> --
> >> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> >> Lecturer in Bioinformatics,             Email:
> >> phillip.lord@newcastle.ac.uk
> >> School of Computing Science,
> >> http://homepages.cs.ncl.ac.uk/phillip.lord
> >> Room 914 Claremont Tower,               skype: russet_apples
> >> Newcastle University,                   twitter: phillord
> >> NE1 7RU
> >>
>
> --
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics,             Email:
> phillip.lord@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,               skype: russet_apples
> Newcastle University,                   twitter: phillord
> NE1 7RU
>

Re: Precompiled Emacs

[Stefan Monnier]

> I guess I could do:

> $ ./configure --prefix /usr/local/emacs-x.y.z --without-all --without-x
> $ make bootstrap
> $ tar ...

> ... move to another system

> $ make install

Almost.  You could use:

   $ ./configure --without-all --without-x
   $ make bootstrap
   $ tar ...
   ... move to another system
   $ make install prefix=/where/ever/I/like

Actually, you could also install it "anywhere" and then copy the
installed files to /where/ever/I/like.  Emacs will have a bit of trouble
finding its files, but there is code in Emacs already to try and find
its own files in such situations (used for the Windows and OS X builds,
IIRC), and I'd welcome a patch which extends this to GNU/Linux
(especially if it can reuse/consolidate the existing code).


        Stefan

Re: Precompiled Emacs

[Phillip Lord]

Okay, now I understand. This is a good aim, and would be a good thing to
do. You are right about wanting to test between point releases -- in
fact, for testing, this is more valuable than between major releases, I
think.

In a sense, I am not sure that I would be worried about speed of
installation -- as this is largely useful for package developers, and
it's a per emacs release cost (multiplied by the number of machines a
developer has).

However, given that this is for testing, from my own perspective, I
would prefer not to mess around with my main installation; that is, I
want my own version of Emacs and the rest of my system untouched. So,
why not compile Emacs, and then just launch it from the directory in
which it is built? To precompile, simply untar the distribution,
./configure, make, and then retar everything. This should be pretty
platform independent, doesn't require root, and if you put everything in
one place means a simple delete cleans everything up. It also has the
advantage that the Emacs in question is relative clean (i.e. not patched
by any downstream distributor) which is a useful test in itself.

Phil


Johan Andersson <johan.rejeep@gmail.com> writes:

> Sure, sorry if I am unclear.
>
> I have a project called EVM - Emacs Version Manager (
> https://github.com/rejeep/evm). The idea with the project is that it should
> be possible to install and easily switch between different Emacs version.
> The primary (but not only) usage of this package is that Emacs developers
> should be able to test their package against a lot of different versions.
> Emacs-23 and Emacs-24 is not good enough. I just recently noticed that one
> of my packages worked fine in 24.3, but not in 24.1 and 24.2.
>
> EVM in its current state works fine, but you have to compile Emacs from
> scratch. To allow for setting up this kind of testing on for example Travis
> CI, I want to provide pre compiled binaries, because it takes too long time
> to build Emacs from source.
>
> Basically, I want to be able to do this:
>
> for version in emacs-23.4*-bin* emacs-24.1*-bin* emacs-24.2*-bin* emacs-24.3
> *-bin* emacs-git-trunk*-bin*; do
>   evm install $version
>   evm use $version
>   cd /path/to/my/project
>   make test
> done
>
> Hope this makes it a bit more clear of what I'm trying to achieve.
>
>
> On Mon, Nov 4, 2013 at 2:21 PM, Phillip Lord
> <phillip.lord@newcastle.ac.uk>wrote:
>
>>
>>
>> Well, I have both emacs23 and emacs24 installed on my machine. And there
>> is alternatives support. But still this is all black-box guess work.
>> Instead of saying what you do not way to do, can you explain what you
>> are trying to achieve in the first place? So far I have got:
>>
>> 1) You want to install Emacs on different linux distros
>> 2) You want to use a precompiled distribution for speed of installation
>> 3) You want to be able to use different versions
>> 4) You want to have it work on any distribution
>>
>> My own feeling is that 1-3 can be done with a package manager and that
>> 4 can't be done with anything, but that is irrelevant as someone has
>> already done it for almost all distros.
>>
>> If you can describe what you exact use case is, then you would probably
>> get better advice.
>>
>> Phil
>>
>>
>> Johan Andersson <johan.rejeep@gmail.com> writes:
>>
>> > I don't want to use a package manager, because they do not support enough
>> > versions and there is usually no way of switching between different
>> > versions.
>> >
>> >
>> > On Mon, Nov 4, 2013 at 12:46 PM, Phillip Lord
>> > <phillip.lord@newcastle.ac.uk>wrote:
>> >
>> >>
>> >> But you don't say why!
>> >>
>> >> If you want to build a prebuilt binary which will install in a sane way,
>> >> then building something for the appropriate package management system
>> >> seems the sensible way. Your only stated aim (fast installations,
>> >> multiple versions) is fulfilled with this solution.
>> >>
>> >> But, emacs packages already exist for most distributions. So using one
>> >> of these makes most sense. Unless you want to extend and modify emacs in
>> >> some way; but if you want to do this, then, probably package.el will be
>> >> enough.
>> >>
>> >> Phil
>> >>
>> >>
>> >>
>> >>
>> >> Johan Andersson <johan.rejeep@gmail.com> writes:
>> >>
>> >> >> You don't say what distribution you are working with.
>> >> >
>> >> > Any, that's the idea.
>> >> >
>> >> >
>> >> > On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <kjambunathan@gmail.com
>> >> >wrote:
>> >> >
>> >> >>
>> >> >> You don't say what distribution you are working with.  Why not mess
>> >> >> around with the distributed deb-srcs and make a custom .deb out of
>> it.
>> >> >>
>> >> >> As you see below, you can choose one among the many different
>> >> >> alternatives for emacs.
>> >> >>
>> >> >> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
>> >> >>    5792 Dec 11  2010 b2m.emacs23
>> >> >>   82760 Dec 11  2010 ctags.emacs23
>> >> >>    3309 Aug  7  2010 dh_installemacsen
>> >> >>   34780 Dec 11  2010 ebrowse.emacs23
>> >> >>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
>> >> >>       9 Aug 18 15:54 emacs23 -> emacs23-x
>> >> >> 6583560 Dec 11  2010 emacs23-x
>> >> >>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
>> >> >>   16816 Dec 11  2010 emacsclient.emacs23
>> >> >>   81064 Dec 11  2010 etags.emacs23
>> >> >>    7294 Dec 11  2010 grep-changelog.emacs23
>> >> >>    3983 Dec 11  2010 rcs-checkin.emacs23
>> >> >>
>> >> >>
>> >> >> Johan Andersson <johan.rejeep@gmail.com> writes:
>> >> >>
>> >> >> > Well, the thing is that I don't want to install it there. I guess
>> it's
>> >> >> not
>> >> >> > possible to compile Emacs, archive it, move to another machine and
>> >> there
>> >> >> > "make install" to the desired prefix?
>> >> >> >
>> >> >> > The purpose of this is to allow for fast installations and at the
>> same
>> >> >> time
>> >> >> > allow for multiple Emacs version. So that will not work with
>> >> >> > "/usr/local/emacs".
>> >> >> >
>> >> >> > I guess I could do:
>> >> >> >
>> >> >> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all
>> >> --without-x
>> >> >> > $ make bootstrap
>> >> >> > $ tar ...
>> >> >> >
>> >> >> > ... move to another system
>> >> >> >
>> >> >> > $ make install
>> >> >> >
>> >> >> > That would mean a larger tar-file. But I guess I could "make
>> install"
>> >> on
>> >> >> > the compile system and then tar "/usr/local/emacs-x.y.z".
>> >> >> >
>> >> >> > Still... seems a bit weird that this limitation exists. Maybe
>> there's
>> >> a
>> >> >> > good reason for it?
>> >> >> >
>> >> >> >
>> >> >> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <
>> >> kai.grossjohann@gmx.net
>> >> >> >wrote:
>> >> >> >
>> >> >> >> Johan Andersson wrote:
>> >> >> >> > I've read the instructions in INSTALL, which are very good. I
>> tried
>> >> >> and
>> >> >> >> did
>> >> >> >> > a build with:
>> >> >> >> >
>> >> >> >> > $ ./configure --prefix emacs-install --without-all --without-x
>> >> >> >>
>> >> >> >> The assumption is that the argument of --prefix is the fully
>> >> qualified
>> >> >> >> directory name where Emacs is installed.  If you omit --prefix, it
>> >> will
>> >> >> >> use /usr/local.
>> >> >> >>
>> >> >> >> Conventionally, people are expected to use values such as
>> >> >> >> /usr/local/emacs or /opt/emacs or something.
>> >> >> >>
>> >> >> >> Kai
>> >> >> >>
>> >> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >> --
>> >> Phillip Lord,                           Phone: +44 (0) 191 222 7827
>> >> Lecturer in Bioinformatics,             Email:
>> >> phillip.lord@newcastle.ac.uk
>> >> School of Computing Science,
>> >> http://homepages.cs.ncl.ac.uk/phillip.lord
>> >> Room 914 Claremont Tower,               skype: russet_apples
>> >> Newcastle University,                   twitter: phillord
>> >> NE1 7RU
>> >>
>>
>> --
>> Phillip Lord,                           Phone: +44 (0) 191 222 7827
>> Lecturer in Bioinformatics,             Email:
>> phillip.lord@newcastle.ac.uk
>> School of Computing Science,
>> http://homepages.cs.ncl.ac.uk/phillip.lord
>> Room 914 Claremont Tower,               skype: russet_apples
>> Newcastle University,                   twitter: phillord
>> NE1 7RU
>>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: Precompiled Emacs

[Jambunathan K]

Will Hydra help in this case?

    http://hydra.nixos.org/jobset/gnu/emacs-trunk

Can one simply download the already built binaries and "deploy" it
locally for testing?  If the tester has infinite bandwidth it might be a
more scalable and hassle-free solution.

Just throwing things.  Don't know what I am speaking.


Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I guess I could do:
>
>> $ ./configure --prefix /usr/local/emacs-x.y.z --without-all --without-x
>> $ make bootstrap
>> $ tar ...
>
>> ... move to another system
>
>> $ make install
>
> Almost.  You could use:
>
>    $ ./configure --without-all --without-x
>    $ make bootstrap
>    $ tar ...
>    ... move to another system
>    $ make install prefix=/where/ever/I/like
>
> Actually, you could also install it "anywhere" and then copy the
> installed files to /where/ever/I/like.  Emacs will have a bit of trouble
> finding its files, but there is code in Emacs already to try and find
> its own files in such situations (used for the Windows and OS X builds,
> IIRC), and I'd welcome a patch which extends this to GNU/Linux
> (especially if it can reuse/consolidate the existing code).
>
>
>         Stefan

Re: Precompiled Emacs

[Stefan Monnier]

> The primary (but not only) usage of this package is that Emacs developers
> should be able to test their package against a lot of different versions.

FWIW, on Debian systems, you can install Emacs-19 to Emacs-24, all at
the same time (tho not, for example, Emacs-24.1 and Emacs-24.3 at the
same time).

I know, because that's what I have ;-)

IIRC I had to fiddle a bit, adding a meta/pseudo package to satisfy
a dependency, but I did that once eons ago and never looked back.


        Stefan

Re: Precompiled Emacs

[David Engster]

Stefan Monnier writes:
> FWIW, on Debian systems, you can install Emacs-19 to Emacs-24, all at
> the same time (tho not, for example, Emacs-24.1 and Emacs-24.3 at the
> same time).
>
> I know, because that's what I have ;-)

Wow. How did you do that? It took me quite some manual fiddling with the
Makefiles just to compile Emacs 23.2 on Debian Wheezy for the Buildbot,
and the resulting binary isn't even working correctly...

-David

Re: Precompiled Emacs

[Stefan Monnier]

> Wow. How did you do that? It took me quite some manual fiddling with the
> Makefiles just to compile Emacs 23.2 on Debian Wheezy for the Buildbot,
> and the resulting binary isn't even working correctly...

I didn't compile anything.  Just installed Debian's emacs19, emacs20,
emacs21, emacs22, ...
Indeed, some of those could required non-trivial work to compile them on
current systems, but their binary still run fine, thanks to the
versioning support in ld.so.


        Stefan

Re: Precompiled Emacs

[David Engster]

Stefan Monnier writes:
> I didn't compile anything.  Just installed Debian's emacs19, emacs20,
> emacs21, emacs22, ...

Ah OK. You already mentioned that you can only install major versions
this way and not different point releases, but unfortunately I need
Emacs 23.2... I guess I could install the 'emacs' from oldstable and
compile 23.4 by hand (which is the version from current stable).

> Indeed, some of those could required non-trivial work to compile them on
> current systems

Well, I was surprised to see that compiling Emacs 23.2 is already a
problem, given that it was released in 2010, which isn't *that* old, and
Debian isn't exactly what one would call a bleeding edge distribution.

-David

Re: Precompiled Emacs

[Johan Andersson]

The compile time is an issue on Travis.

If I ./configure, make and re-tar like you say, will there not be any
hard-coded paths that will be incorrect on some other machine.
On Nov 4, 2013 3:39 PM, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:

>
>
> Okay, now I understand. This is a good aim, and would be a good thing to
> do. You are right about wanting to test between point releases -- in
> fact, for testing, this is more valuable than between major releases, I
> think.
>
> In a sense, I am not sure that I would be worried about speed of
> installation -- as this is largely useful for package developers, and
> it's a per emacs release cost (multiplied by the number of machines a
> developer has).
>
> However, given that this is for testing, from my own perspective, I
> would prefer not to mess around with my main installation; that is, I
> want my own version of Emacs and the rest of my system untouched. So,
> why not compile Emacs, and then just launch it from the directory in
> which it is built? To precompile, simply untar the distribution,
> ./configure, make, and then retar everything. This should be pretty
> platform independent, doesn't require root, and if you put everything in
> one place means a simple delete cleans everything up. It also has the
> advantage that the Emacs in question is relative clean (i.e. not patched
> by any downstream distributor) which is a useful test in itself.
>
> Phil
>
>
> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> > Sure, sorry if I am unclear.
> >
> > I have a project called EVM - Emacs Version Manager (
> > https://github.com/rejeep/evm). The idea with the project is that it
> should
> > be possible to install and easily switch between different Emacs version.
> > The primary (but not only) usage of this package is that Emacs developers
> > should be able to test their package against a lot of different versions.
> > Emacs-23 and Emacs-24 is not good enough. I just recently noticed that
> one
> > of my packages worked fine in 24.3, but not in 24.1 and 24.2.
> >
> > EVM in its current state works fine, but you have to compile Emacs from
> > scratch. To allow for setting up this kind of testing on for example
> Travis
> > CI, I want to provide pre compiled binaries, because it takes too long
> time
> > to build Emacs from source.
> >
> > Basically, I want to be able to do this:
> >
> > for version in emacs-23.4*-bin* emacs-24.1*-bin* emacs-24.2*-bin*
> emacs-24.3
> > *-bin* emacs-git-trunk*-bin*; do
> >   evm install $version
> >   evm use $version
> >   cd /path/to/my/project
> >   make test
> > done
> >
> > Hope this makes it a bit more clear of what I'm trying to achieve.
> >
> >
> > On Mon, Nov 4, 2013 at 2:21 PM, Phillip Lord
> > <phillip.lord@newcastle.ac.uk>wrote:
> >
> >>
> >>
> >> Well, I have both emacs23 and emacs24 installed on my machine. And there
> >> is alternatives support. But still this is all black-box guess work.
> >> Instead of saying what you do not way to do, can you explain what you
> >> are trying to achieve in the first place? So far I have got:
> >>
> >> 1) You want to install Emacs on different linux distros
> >> 2) You want to use a precompiled distribution for speed of installation
> >> 3) You want to be able to use different versions
> >> 4) You want to have it work on any distribution
> >>
> >> My own feeling is that 1-3 can be done with a package manager and that
> >> 4 can't be done with anything, but that is irrelevant as someone has
> >> already done it for almost all distros.
> >>
> >> If you can describe what you exact use case is, then you would probably
> >> get better advice.
> >>
> >> Phil
> >>
> >>
> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >>
> >> > I don't want to use a package manager, because they do not support
> enough
> >> > versions and there is usually no way of switching between different
> >> > versions.
> >> >
> >> >
> >> > On Mon, Nov 4, 2013 at 12:46 PM, Phillip Lord
> >> > <phillip.lord@newcastle.ac.uk>wrote:
> >> >
> >> >>
> >> >> But you don't say why!
> >> >>
> >> >> If you want to build a prebuilt binary which will install in a sane
> way,
> >> >> then building something for the appropriate package management system
> >> >> seems the sensible way. Your only stated aim (fast installations,
> >> >> multiple versions) is fulfilled with this solution.
> >> >>
> >> >> But, emacs packages already exist for most distributions. So using
> one
> >> >> of these makes most sense. Unless you want to extend and modify
> emacs in
> >> >> some way; but if you want to do this, then, probably package.el will
> be
> >> >> enough.
> >> >>
> >> >> Phil
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >> >>
> >> >> >> You don't say what distribution you are working with.
> >> >> >
> >> >> > Any, that's the idea.
> >> >> >
> >> >> >
> >> >> > On Mon, Nov 4, 2013 at 9:25 AM, Jambunathan K <
> kjambunathan@gmail.com
> >> >> >wrote:
> >> >> >
> >> >> >>
> >> >> >> You don't say what distribution you are working with.  Why not
> mess
> >> >> >> around with the distributed deb-srcs and make a custom .deb out of
> >> it.
> >> >> >>
> >> >> >> As you see below, you can choose one among the many different
> >> >> >> alternatives for emacs.
> >> >> >>
> >> >> >> kjambunathan@debian-6:/usr/bin$ ls -al | grep emacs
> >> >> >>    5792 Dec 11  2010 b2m.emacs23
> >> >> >>   82760 Dec 11  2010 ctags.emacs23
> >> >> >>    3309 Aug  7  2010 dh_installemacsen
> >> >> >>   34780 Dec 11  2010 ebrowse.emacs23
> >> >> >>      23 Aug 18 15:54 emacs -> /etc/alternatives/emacs
> >> >> >>       9 Aug 18 15:54 emacs23 -> emacs23-x
> >> >> >> 6583560 Dec 11  2010 emacs23-x
> >> >> >>      29 Aug 18 15:54 emacsclient -> /etc/alternatives/emacsclient
> >> >> >>   16816 Dec 11  2010 emacsclient.emacs23
> >> >> >>   81064 Dec 11  2010 etags.emacs23
> >> >> >>    7294 Dec 11  2010 grep-changelog.emacs23
> >> >> >>    3983 Dec 11  2010 rcs-checkin.emacs23
> >> >> >>
> >> >> >>
> >> >> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >> >> >>
> >> >> >> > Well, the thing is that I don't want to install it there. I
> guess
> >> it's
> >> >> >> not
> >> >> >> > possible to compile Emacs, archive it, move to another machine
> and
> >> >> there
> >> >> >> > "make install" to the desired prefix?
> >> >> >> >
> >> >> >> > The purpose of this is to allow for fast installations and at
> the
> >> same
> >> >> >> time
> >> >> >> > allow for multiple Emacs version. So that will not work with
> >> >> >> > "/usr/local/emacs".
> >> >> >> >
> >> >> >> > I guess I could do:
> >> >> >> >
> >> >> >> > $ ./configure --prefix /usr/local/emacs-x.y.z --without-all
> >> >> --without-x
> >> >> >> > $ make bootstrap
> >> >> >> > $ tar ...
> >> >> >> >
> >> >> >> > ... move to another system
> >> >> >> >
> >> >> >> > $ make install
> >> >> >> >
> >> >> >> > That would mean a larger tar-file. But I guess I could "make
> >> install"
> >> >> on
> >> >> >> > the compile system and then tar "/usr/local/emacs-x.y.z".
> >> >> >> >
> >> >> >> > Still... seems a bit weird that this limitation exists. Maybe
> >> there's
> >> >> a
> >> >> >> > good reason for it?
> >> >> >> >
> >> >> >> >
> >> >> >> > On Sun, Nov 3, 2013 at 10:43 PM, Kai Großjohann <
> >> >> kai.grossjohann@gmx.net
> >> >> >> >wrote:
> >> >> >> >
> >> >> >> >> Johan Andersson wrote:
> >> >> >> >> > I've read the instructions in INSTALL, which are very good. I
> >> tried
> >> >> >> and
> >> >> >> >> did
> >> >> >> >> > a build with:
> >> >> >> >> >
> >> >> >> >> > $ ./configure --prefix emacs-install --without-all
> --without-x
> >> >> >> >>
> >> >> >> >> The assumption is that the argument of --prefix is the fully
> >> >> qualified
> >> >> >> >> directory name where Emacs is installed.  If you omit
> --prefix, it
> >> >> will
> >> >> >> >> use /usr/local.
> >> >> >> >>
> >> >> >> >> Conventionally, people are expected to use values such as
> >> >> >> >> /usr/local/emacs or /opt/emacs or something.
> >> >> >> >>
> >> >> >> >> Kai
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >> --
> >> >> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> >> >> Lecturer in Bioinformatics,             Email:
> >> >> phillip.lord@newcastle.ac.uk
> >> >> School of Computing Science,
> >> >> http://homepages.cs.ncl.ac.uk/phillip.lord
> >> >> Room 914 Claremont Tower,               skype: russet_apples
> >> >> Newcastle University,                   twitter: phillord
> >> >> NE1 7RU
> >> >>
> >>
> >> --
> >> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> >> Lecturer in Bioinformatics,             Email:
> >> phillip.lord@newcastle.ac.uk
> >> School of Computing Science,
> >> http://homepages.cs.ncl.ac.uk/phillip.lord
> >> Room 914 Claremont Tower,               skype: russet_apples
> >> Newcastle University,                   twitter: phillord
> >> NE1 7RU
> >>
>
> --
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics,             Email:
> phillip.lord@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,               skype: russet_apples
> Newcastle University,                   twitter: phillord
> NE1 7RU
>

Re: Precompiled Emacs

[Eli Zaretskii]

> From: David Engster <deng@randomsample.de>
> Date: Mon, 04 Nov 2013 20:29:16 +0100
> 
> Well, I was surprised to see that compiling Emacs 23.2 is already a
> problem, given that it was released in 2010, which isn't *that* old, and
> Debian isn't exactly what one would call a bleeding edge distribution.

Unfortunately, it's a sad reality.  If you want to be able to build
old versions reliably, you need to keep the tools you used back then.

Re: Precompiled Emacs

[Stefan Monnier]

> this way and not different point releases, but unfortunately I need
> Emacs 23.2... I guess I could install the 'emacs' from oldstable and
> compile 23.4 by hand (which is the version from current stable).

You can probably find a Debian package for 23.2 in the snapshot archives.

>> Indeed, some of those could required non-trivial work to compile them on
>> current systems
> Well, I was surprised to see that compiling Emacs 23.2 is already a
> problem, given that it was released in 2010, which isn't *that* old, and
> Debian isn't exactly what one would call a bleeding edge distribution.

Crazy, eh?


        Stefan

Re: Precompiled Emacs

[David Engster]

Stefan Monnier writes:
>> this way and not different point releases, but unfortunately I need
>> Emacs 23.2... I guess I could install the 'emacs' from oldstable and
>> compile 23.4 by hand (which is the version from current stable).
>
> You can probably find a Debian package for 23.2 in the snapshot archives.

It's in 'oldstable', so that's not a problem, but installing it would
downgrade the installed 'emacs' package from Debian 7.

-David

Re: Precompiled Emacs

[David Engster]

Eli Zaretskii writes:
>> From: David Engster <deng@randomsample.de>
>> Date: Mon, 04 Nov 2013 20:29:16 +0100
>> 
>> Well, I was surprised to see that compiling Emacs 23.2 is already a
>> problem, given that it was released in 2010, which isn't *that* old, and
>> Debian isn't exactly what one would call a bleeding edge distribution.
>
> Unfortunately, it's a sad reality.  If you want to be able to build
> old versions reliably, you need to keep the tools you used back then.

Even that's not enough, I'm afraid. I was able to build Emacs 23.2
eventually, but it isn't working properly. When I start it up in a TTY,
it doesn't accept any keyboard input and consumes 100% CPU. It works in
batch-mode for byte-compilation, at least (though cannot spawn any
processes there...).

I even compiled Emacs 23.2 on an old box still running Debian 6, and it
runs fine there, but when I copied it over to Debian 7, it shows the
same broken behavior, so I guess it's a problem with some shared lib.
It's not a big issue, but if I'd be really rigorous about testing with
old versions, I'd probably need to run it in a virtual machine with
Debian 6...

-David

Re: Precompiled Emacs

[Kai Großjohann]

Johan Andersson wrote:

> Well, the thing is that I don't want to install it there. I guess it's not
> possible to compile Emacs, archive it, move to another machine and there
> "make install" to the desired prefix?

Hm.  On Windows, you can just unpack the zip file in any directory and
run it from there.  So there must be code in Emacs that knows to find
the other directories based on where you unzipped the zip file.  But I
confess that I don't know any details.

At least load-path and data-directory need to be set to the correct
values, I don't know how that works.  But you could study the source
code to see.

However, it may be easier if you just designate a specific directory to
be the root directory of your packages, then tell folks to make sure
that directory exists.  Or you tell them to create a symlink pointing to
the real Emacs.

For example, if you say that /opt/sw/<packagename> is the root directory
that packages expect, then folks can install in
/home/mumble/programs/emacs-23.4 and create a symlink /opt/sw/emacs
pointing to /home/mumble/programs/emacs-23.4 and off they go.  (Or they
install in /opt/sw/emacs in the first place; this may be even easier.)

Sorry that I've not invested the time to study the source code myself.

./kai

Re: Precompiled Emacs

[Eli Zaretskii]

> Date: Mon, 04 Nov 2013 22:32:32 +0100
> From: Kai Großjohann <kai.grossjohann@gmx.net>
> Cc: help-gnu-emacs@gnu.org, Jambunathan K <kjambunathan@gmail.com>
> 
> Johan Andersson wrote:
> 
> > Well, the thing is that I don't want to install it there. I guess it's not
> > possible to compile Emacs, archive it, move to another machine and there
> > "make install" to the desired prefix?
> 
> Hm.  On Windows, you can just unpack the zip file in any directory and
> run it from there.  So there must be code in Emacs that knows to find
> the other directories based on where you unzipped the zip file.

That code is Windows-specific, it isn't compiled on other platforms.

Re: Precompiled Emacs

[Glenn Morris]

David Engster wrote:

> Even that's not enough, I'm afraid. I was able to build Emacs 23.2
> eventually, but it isn't working properly. When I start it up in a TTY,
> it doesn't accept any keyboard input and consumes 100% CPU.

IIRC, that's
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9754

Re: Precompiled Emacs

[Phillip Lord]

I didn't know the answer to this, so I tried it out. Sadly, the answer
is yes, including in the make file as far as I can see. The only reason
that Emacs normally works in this way is because it's already installed.

I tried doing ./configure like so...

./configure --without-all --prefix=/tmp --exec-prefix=/tmp

with the hope that the built emacs could be transferred to another
machine and then make installed, but that doesn't work (I don't quite
know why). Besides you would now be dependent on the build tools which
change over time as others have said.

For travis, I think the best option is to use a PPA and install into
that. Emacs does support multiple minor version installations. But, you
lose multiple platform testing. 

Other than that I am all out of ideas!

Phil




Johan Andersson <johan.rejeep@gmail.com> writes:

> The compile time is an issue on Travis.
>
> If I ./configure, make and re-tar like you say, will there not be any
> hard-coded paths that will be incorrect on some other machine.
> On Nov 4, 2013 3:39 PM, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
>
>>
>>
>> Okay, now I understand. This is a good aim, and would be a good thing to
>> do. You are right about wanting to test between point releases -- in
>> fact, for testing, this is more valuable than between major releases, I
>> think.
>>
>> In a sense, I am not sure that I would be worried about speed of
>> installation -- as this is largely useful for package developers, and
>> it's a per emacs release cost (multiplied by the number of machines a
>> developer has).
>>
>> However, given that this is for testing, from my own perspective, I
>> would prefer not to mess around with my main installation; that is, I
>> want my own version of Emacs and the rest of my system untouched. So,
>> why not compile Emacs, and then just launch it from the directory in
>> which it is built? To precompile, simply untar the distribution,
>> ./configure, make, and then retar everything. This should be pretty
>> platform independent, doesn't require root, and if you put everything in
>> one place means a simple delete cleans everything up. It also has the
>> advantage that the Emacs in question is relative clean (i.e. not patched
>> by any downstream distributor) which is a useful test in itself.

Re: Precompiled Emacs

[Johan Andersson]

I'm thinking I could tell Evm users to create /usr/local/evm and make it
accessible. Pre compiled installations would have to be installed there. If
they do not like it, they could always compile from source.


On Tue, Nov 5, 2013 at 1:35 PM, Phillip Lord
<phillip.lord@newcastle.ac.uk>wrote:

>
>
> I didn't know the answer to this, so I tried it out. Sadly, the answer
> is yes, including in the make file as far as I can see. The only reason
> that Emacs normally works in this way is because it's already installed.
>
> I tried doing ./configure like so...
>
> ./configure --without-all --prefix=/tmp --exec-prefix=/tmp
>
> with the hope that the built emacs could be transferred to another
> machine and then make installed, but that doesn't work (I don't quite
> know why). Besides you would now be dependent on the build tools which
> change over time as others have said.
>
> For travis, I think the best option is to use a PPA and install into
> that. Emacs does support multiple minor version installations. But, you
> lose multiple platform testing.
>
> Other than that I am all out of ideas!
>
> Phil
>
>
>
>
> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> > The compile time is an issue on Travis.
> >
> > If I ./configure, make and re-tar like you say, will there not be any
> > hard-coded paths that will be incorrect on some other machine.
> > On Nov 4, 2013 3:39 PM, "Phillip Lord" <phillip.lord@newcastle.ac.uk>
> wrote:
> >
> >>
> >>
> >> Okay, now I understand. This is a good aim, and would be a good thing to
> >> do. You are right about wanting to test between point releases -- in
> >> fact, for testing, this is more valuable than between major releases, I
> >> think.
> >>
> >> In a sense, I am not sure that I would be worried about speed of
> >> installation -- as this is largely useful for package developers, and
> >> it's a per emacs release cost (multiplied by the number of machines a
> >> developer has).
> >>
> >> However, given that this is for testing, from my own perspective, I
> >> would prefer not to mess around with my main installation; that is, I
> >> want my own version of Emacs and the rest of my system untouched. So,
> >> why not compile Emacs, and then just launch it from the directory in
> >> which it is built? To precompile, simply untar the distribution,
> >> ./configure, make, and then retar everything. This should be pretty
> >> platform independent, doesn't require root, and if you put everything in
> >> one place means a simple delete cleans everything up. It also has the
> >> advantage that the Emacs in question is relative clean (i.e. not patched
> >> by any downstream distributor) which is a useful test in itself.
>

Re: Precompiled Emacs

[David Engster]

Glenn Morris writes:
> David Engster wrote:
>
>> Even that's not enough, I'm afraid. I was able to build Emacs 23.2
>> eventually, but it isn't working properly. When I start it up in a TTY,
>> it doesn't accept any keyboard input and consumes 100% CPU.
>
> IIRC, that's
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=9754

Glenn, you human debbugs! I compiled with Lucid and dropped everything
needing glib, and it works now.

Thanks!
David

Re: Precompiled Emacs

[Stefan Monnier]

> That code is Windows-specific, it isn't compiled on other platforms.

If someone can try and make it work across platforms, patch welcome.


        Stefan

Re: Precompiled Emacs

[Glenn Morris]

Stefan Monnier wrote:

>> That code is Windows-specific, it isn't compiled on other platforms.
>
> If someone can try and make it work across platforms, patch welcome.

BTW, this is http://debbugs.gnu.org/12123 .
(Personally, I think all the talk about progreloc there is a bit of a
red herring.)

Re: Precompiled Emacs

[Kai Großjohann]

It may make sense to run Emacs from the directory it is compiled in
(without installation).  That might work without any fuss.

Kai


Phillip Lord wrote:
> 
> I didn't know the answer to this, so I tried it out. Sadly, the answer
> is yes, including in the make file as far as I can see. The only reason
> that Emacs normally works in this way is because it's already installed.
> 
> I tried doing ./configure like so...
> 
> ./configure --without-all --prefix=/tmp --exec-prefix=/tmp
> 
> with the hope that the built emacs could be transferred to another
> machine and then make installed, but that doesn't work (I don't quite
> know why). Besides you would now be dependent on the build tools which
> change over time as others have said.
> 
> For travis, I think the best option is to use a PPA and install into
> that. Emacs does support multiple minor version installations. But, you
> lose multiple platform testing. 
> 
> Other than that I am all out of ideas!
> 
> Phil
> 
> 
> 
> 
> Johan Andersson <johan.rejeep@gmail.com> writes:
> 
>> The compile time is an issue on Travis.
>>
>> If I ./configure, make and re-tar like you say, will there not be any
>> hard-coded paths that will be incorrect on some other machine.
>> On Nov 4, 2013 3:39 PM, "Phillip Lord" <phillip.lord@newcastle.ac.uk> wrote:
>>
>>>
>>> Okay, now I understand. This is a good aim, and would be a good thing to
>>> do. You are right about wanting to test between point releases -- in
>>> fact, for testing, this is more valuable than between major releases, I
>>> think.
>>>
>>> In a sense, I am not sure that I would be worried about speed of
>>> installation -- as this is largely useful for package developers, and
>>> it's a per emacs release cost (multiplied by the number of machines a
>>> developer has).
>>>
>>> However, given that this is for testing, from my own perspective, I
>>> would prefer not to mess around with my main installation; that is, I
>>> want my own version of Emacs and the rest of my system untouched. So,
>>> why not compile Emacs, and then just launch it from the directory in
>>> which it is built? To precompile, simply untar the distribution,
>>> ./configure, make, and then retar everything. This should be pretty
>>> platform independent, doesn't require root, and if you put everything in
>>> one place means a simple delete cleans everything up. It also has the
>>> advantage that the Emacs in question is relative clean (i.e. not patched
>>> by any downstream distributor) which is a useful test in itself.
> 
> 

Re: Precompiled Emacs

[Phillip Lord]

I think this sounds reasonable; the alternative of /tmp/evm is nice but
will get deleted frequently, and /tmp runs out of space on some
machines. It's not as nice as ~/.evm but it's workable.

I think having the installations separable from main emacs is good, as
these are often customised.

Phil

Johan Andersson <johan.rejeep@gmail.com> writes:

> I'm thinking I could tell Evm users to create /usr/local/evm and make it
> accessible. Pre compiled installations would have to be installed there. If
> they do not like it, they could always compile from source.
>
>
> On Tue, Nov 5, 2013 at 1:35 PM, Phillip Lord
> <phillip.lord@newcastle.ac.uk>wrote:
>
>>
>>
>> I didn't know the answer to this, so I tried it out. Sadly, the answer
>> is yes, including in the make file as far as I can see. The only reason
>> that Emacs normally works in this way is because it's already installed.
>>
>> I tried doing ./configure like so...
>>
>> ./configure --without-all --prefix=/tmp --exec-prefix=/tmp
>>
>> with the hope that the built emacs could be transferred to another
>> machine and then make installed, but that doesn't work (I don't quite
>> know why). Besides you would now be dependent on the build tools which
>> change over time as others have said.
>>
>> For travis, I think the best option is to use a PPA and install into
>> that. Emacs does support multiple minor version installations. But, you
>> lose multiple platform testing.
>>
>> Other than that I am all out of ideas!
>>
>> Phil
>>
>>
>>
>>
>> Johan Andersson <johan.rejeep@gmail.com> writes:
>>
>> > The compile time is an issue on Travis.
>> >
>> > If I ./configure, make and re-tar like you say, will there not be any
>> > hard-coded paths that will be incorrect on some other machine.
>> > On Nov 4, 2013 3:39 PM, "Phillip Lord" <phillip.lord@newcastle.ac.uk>
>> wrote:
>> >
>> >>
>> >>
>> >> Okay, now I understand. This is a good aim, and would be a good thing to
>> >> do. You are right about wanting to test between point releases -- in
>> >> fact, for testing, this is more valuable than between major releases, I
>> >> think.
>> >>
>> >> In a sense, I am not sure that I would be worried about speed of
>> >> installation -- as this is largely useful for package developers, and
>> >> it's a per emacs release cost (multiplied by the number of machines a
>> >> developer has).
>> >>
>> >> However, given that this is for testing, from my own perspective, I
>> >> would prefer not to mess around with my main installation; that is, I
>> >> want my own version of Emacs and the rest of my system untouched. So,
>> >> why not compile Emacs, and then just launch it from the directory in
>> >> which it is built? To precompile, simply untar the distribution,
>> >> ./configure, make, and then retar everything. This should be pretty
>> >> platform independent, doesn't require root, and if you put everything in
>> >> one place means a simple delete cleans everything up. It also has the
>> >> advantage that the Emacs in question is relative clean (i.e. not patched
>> >> by any downstream distributor) which is a useful test in itself.
>>

-- 
Phillip Lord,                           Phone: +44 (0) 191 222 7827
Lecturer in Bioinformatics,             Email: phillip.lord@newcastle.ac.uk
School of Computing Science,            http://homepages.cs.ncl.ac.uk/phillip.lord
Room 914 Claremont Tower,               skype: russet_apples
Newcastle University,                   twitter: phillord
NE1 7RU                                 

Re: Precompiled Emacs

[Johan Andersson]

> It's not as nice as ~/.evm but it's workable.

I don't think this would even would because the path is most likely
extended to absolute. Not sure though.


On Wed, Nov 6, 2013 at 11:18 AM, Phillip Lord
<phillip.lord@newcastle.ac.uk>wrote:

>
>
> I think this sounds reasonable; the alternative of /tmp/evm is nice but
> will get deleted frequently, and /tmp runs out of space on some
> machines. It's not as nice as ~/.evm but it's workable.
>
> I think having the installations separable from main emacs is good, as
> these are often customised.
>
> Phil
>
> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> > I'm thinking I could tell Evm users to create /usr/local/evm and make it
> > accessible. Pre compiled installations would have to be installed there.
> If
> > they do not like it, they could always compile from source.
> >
> >
> > On Tue, Nov 5, 2013 at 1:35 PM, Phillip Lord
> > <phillip.lord@newcastle.ac.uk>wrote:
> >
> >>
> >>
> >> I didn't know the answer to this, so I tried it out. Sadly, the answer
> >> is yes, including in the make file as far as I can see. The only reason
> >> that Emacs normally works in this way is because it's already installed.
> >>
> >> I tried doing ./configure like so...
> >>
> >> ./configure --without-all --prefix=/tmp --exec-prefix=/tmp
> >>
> >> with the hope that the built emacs could be transferred to another
> >> machine and then make installed, but that doesn't work (I don't quite
> >> know why). Besides you would now be dependent on the build tools which
> >> change over time as others have said.
> >>
> >> For travis, I think the best option is to use a PPA and install into
> >> that. Emacs does support multiple minor version installations. But, you
> >> lose multiple platform testing.
> >>
> >> Other than that I am all out of ideas!
> >>
> >> Phil
> >>
> >>
> >>
> >>
> >> Johan Andersson <johan.rejeep@gmail.com> writes:
> >>
> >> > The compile time is an issue on Travis.
> >> >
> >> > If I ./configure, make and re-tar like you say, will there not be any
> >> > hard-coded paths that will be incorrect on some other machine.
> >> > On Nov 4, 2013 3:39 PM, "Phillip Lord" <phillip.lord@newcastle.ac.uk>
> >> wrote:
> >> >
> >> >>
> >> >>
> >> >> Okay, now I understand. This is a good aim, and would be a good
> thing to
> >> >> do. You are right about wanting to test between point releases -- in
> >> >> fact, for testing, this is more valuable than between major
> releases, I
> >> >> think.
> >> >>
> >> >> In a sense, I am not sure that I would be worried about speed of
> >> >> installation -- as this is largely useful for package developers, and
> >> >> it's a per emacs release cost (multiplied by the number of machines a
> >> >> developer has).
> >> >>
> >> >> However, given that this is for testing, from my own perspective, I
> >> >> would prefer not to mess around with my main installation; that is, I
> >> >> want my own version of Emacs and the rest of my system untouched. So,
> >> >> why not compile Emacs, and then just launch it from the directory in
> >> >> which it is built? To precompile, simply untar the distribution,
> >> >> ./configure, make, and then retar everything. This should be pretty
> >> >> platform independent, doesn't require root, and if you put
> everything in
> >> >> one place means a simple delete cleans everything up. It also has the
> >> >> advantage that the Emacs in question is relative clean (i.e. not
> patched
> >> >> by any downstream distributor) which is a useful test in itself.
> >>
>
> --
> Phillip Lord,                           Phone: +44 (0) 191 222 7827
> Lecturer in Bioinformatics,             Email:
> phillip.lord@newcastle.ac.uk
> School of Computing Science,
> http://homepages.cs.ncl.ac.uk/phillip.lord
> Room 914 Claremont Tower,               skype: russet_apples
> Newcastle University,                   twitter: phillord
> NE1 7RU
>

Re: Precompiled Emacs

[Phillip Lord]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> That code is Windows-specific, it isn't compiled on other platforms.
>
> If someone can try and make it work across platforms, patch welcome.

Of course, even if there is a patch it won't solve the existing problem
which involves installing existing Emacs versions. A portable Emacs (as
in movable) would be nice though.

Phil

Re: Precompiled Emacs

[Peter Dyballa]

Am 06.11.2013 um 11:24 schrieb Phillip Lord:

> A portable Emacs (as in movable) would be nice though.

Built from static libraries or launched via a shell script that sets LD_LIBRARY_PATH to the interiors of the package, providing these dynamic libraries.

--
Greetings

  Pete

Eat the rich – the poor are tough and stringy.

Re: Precompiled Emacs

[Phillip Lord]

Johan Andersson <johan.rejeep@gmail.com> writes:

>> It's not as nice as ~/.evm but it's workable.
>
> I don't think this would even would because the path is most likely
> extended to absolute. Not sure though.

Agreed. You could do it for travis, since ~ is /home/travis, although
they say not rely on this. Of course, for travis, it's irrelevant as
running as root is fine.

Phil

Re: Precompiled Emacs

[Johan Andersson]

All right, I'll hack this together and let you know when it's done. Thanks
all for your valuable input!


On Wed, Nov 6, 2013 at 2:01 PM, Phillip Lord
<phillip.lord@newcastle.ac.uk>wrote:

> Johan Andersson <johan.rejeep@gmail.com> writes:
>
> >> It's not as nice as ~/.evm but it's workable.
> >
> > I don't think this would even would because the path is most likely
> > extended to absolute. Not sure though.
>
> Agreed. You could do it for travis, since ~ is /home/travis, although
> they say not rely on this. Of course, for travis, it's irrelevant as
> running as root is fine.
>
> Phil
>

Re: Precompiled Emacs

[Johan Andersson]

Been hacking for a while now, works pretty well, check it out:
https://github.com/rejeep/evm


On Wed, Nov 6, 2013 at 2:03 PM, Johan Andersson <johan.rejeep@gmail.com>wrote:

> All right, I'll hack this together and let you know when it's done. Thanks
> all for your valuable input!
>
>
> On Wed, Nov 6, 2013 at 2:01 PM, Phillip Lord <phillip.lord@newcastle.ac.uk
> > wrote:
>
>> Johan Andersson <johan.rejeep@gmail.com> writes:
>>
>> >> It's not as nice as ~/.evm but it's workable.
>> >
>> > I don't think this would even would because the path is most likely
>> > extended to absolute. Not sure though.
>>
>> Agreed. You could do it for travis, since ~ is /home/travis, although
>> they say not rely on this. Of course, for travis, it's irrelevant as
>> running as root is fine.
>>
>> Phil
>>
>
>