help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling emacs 24 under Debian


From: Tim X
Subject: Re: Compiling emacs 24 under Debian
Date: Wed, 05 Jan 2011 09:53:53 +1100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Richard Riley <rileyrg@googlemail.com> writes:

> Hi Tim,
>
> Thanks for the reply. Some Qs below.
>
> Tim X <timx@nospam.dev.null> writes:
>
>> Richard Riley <rileyrg@googlemail.com> writes:
>>
>>> Could someone please share the secret for making emacs 24 under Debian
>>> (testing) so that it can still see the system installed libraries that
>>> are not part of emacs proper?
>>>
>>> I have this but I'm not altogether sure its good enough:-
>>>
>>> (setq load-path (append load-path '("/usr/local/emacs/site-lisp"
>>> "/usr/share/emacs/site-lisp")))
>>> (load-library "debian-startup")
>>> (debian-startup 'emacs23)
>>> (load-library "/etc/emacs/site-start")
>>>
>>
>> The most reliable way I've found is to edit lisp/startuo.el and add the
>> debian-emacs-flavor variable and modify the code further down where the
>> site-start library is loaded. If you do a diff on the startup.el file
>> from debian's emacs and the one from emacs bzr, you will quickly see the
>> necessary changes. 
>
> I just compiled and use only the above as the init : how do you feel
> that compares? Certainly Emacs 24 loads and runs  (it compiled and
> installed to /usr/local/bin). What would it lack do you think? It uses
> the latest emacs installed as its "site lisp" after using the bzr one.
>

Not sure if I follow 100%. However, keep in mind that part of the build
process also involves generating a 'dumped' version of emacs to help
speed up startup. This means there can be some values, loaded in the
dumped image, that cannot be easily overridden later. This is why I
modify the startup.el file rather than just run additional init code to
set various things. I use to just use additional init code at startup,
but found I sometimes got inconsistent load-path outcomes and difficult
to track down bugs. 

The nice thing about how I have things setup now is that updating from
bzr to get the latest emacs sources is a simple as 

cd bzr/emacs/trunk
sudo make distclean
bzr pull
./configure
make bootstrap
sudo make install
sudo lib-src/blessmail ....
cd ~/bin
sudo ./setup-emacs.sh

and I'm done. If the emacs version number changes i.e. 24.0.50 to
24.0.51, I have to do the symlink thing with site-lisp, but that is very
infrequent. 

>>
>> There are some other differences, but I've found these to be cosmetic.
>> The startup.el file rarely changes and bzr will auto merge if possible
>> when you do a bzr pull to update. 
>
> Thats cool.
>
>>
>> As there can be byte code issues between versions of emacs, I also tend
>> to install the emacs-snapshot and set the debian-emacs-flavor to
>> 'emacs-snapshot. I also have 2 simple bash script that I run to setup
>
> Which repos do you use for emacs-snapshot? emacs-snapshot isn't a part
> of Debian Testing, the orebokech one is gone,
> http://www.emacswiki.org/emacs/EmacsSnapshotAndDebian isnt really a
> snapshot (git head).
>

OK, I use to use Ramain's one, if thats gone, I'm not sure (I actually
switched to ubuntu a little while back an have been using a ubuntu
specific snapshot from a PPA.

>> appropriate symlinks and /etc/alternatives. Not necessary, but handy if
>> you want to easily and consistently move between different versions of
>> emacs such that running 'emacs' will give consistent version results. I
>> install emacs into the default /usr/local tree. After running make
>> install, I rm /usr/local/share/emacs/24.0.50/site-lisp and replace it
>> with a sym link to /usr/share/emacs-snapshot/site-lisp
>>
>> I use load-path-shadow to verify everything is consistent and loading
>> what I think it is after each new build of emacs. 
>
> Crikey, certainly a lot more thorough than my way. I will give this a go
> soon : certainly not what I would term simple ;)
>

Well, there is a much simpler method that works really well. However, it
has a steep learning curve. Once you get the workflow sorted though, it
is quite easy. I've used it for other packages, but have never got
around to doing it for the emacs stuff. 

There was a web page somewhere that explained this in a concise step by
step way, but I seem to have lost the link. The principal is pretty
straight-forward. 

1. Grap the deb-src package for emacs 23
2. Unpack it
3. replace the sources with the sources from emacs bzr
4. (Possibly) remove or update any patches.
5. Update the spec file 
6. build a new deb package and install it. 

The biggest hassle with this method (apart from having to get more
familiar with deb internals0 is step 4. However, if you just remove all
patches except those that update startup.el to add the
debian-emacs-flavor and debian-startup stuff, then its straight-forward
enough. Most of the hard work has been done by previous maintainers.

This approach has two main advantages. 

1. You can easily install emacs on multiple machines
2. If you are ever unlucky enough to get an updated emacs bzr version
with a nasty bug, you can quickly and reliably downgrade to the previous
version MUCH easier and faster than you can using a direct bzr method. 

The only reason I've not gone this way is that I already had my current
workflow in place before I learnt enough about deb packages to see how
easy it is to build new packages when you can leverage off existing
packages built for an earlier version.  More recently, I've also started
to seriously question using the debian/ubuntu emacs framework. While I
really liked the ability to install/remove deb versions of emacs
add-ons, there appears to be a drop off in interest in maintaining emacs
for either ubuntu or debian (ubuntu is particularly bad). The packages
are now getting to be very out of date (ubuntu is still shipping with
emacs 23.1!) and I'm finding I'm running with more and more packages
that are not from the deb repositories in order to get recent stable
versions. As my emacs environment is pretty stable and I don't tend to
install many new packages from the deb repositories, I'm seriously
considering just uninstalling the whole lot and keeping my own branches
of what I use and building manually.

Tim

-- 
tcross (at) rapttech dot com dot au


reply via email to

[Prev in Thread] Current Thread [Next in Thread]