[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter describes all aspects of upgrading to a newer version of ECB.
The first section describes how to download and install a new package from the web, where "package" means either ECB itself or the required libraries semantic, eieio and speedbar.
After installing a new ECB-version ECB checks if the values of the customized ECB-options are still compatible. If not ECB does some smart things. This is the topic of the second section.
7.1 Downloading new versions of ECB and/or required packages | How to download newer versions of packages | |
7.2 Automatic upgrading of options | ECB can auto. upgrade your options |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ECB offers the possibility to upgrade to newer versions direct from the ECB-website. This can be done if the following requirements are satisfied:
With Unix-systems these tools are in the
standard-distribution. If you are running any Microsoft Windows system
then you need cygwin(25) which offers these tools too. On every
system these tools must reside in the PATH
environment-variable!
If you are behind a firewall and you have to use a proxy you maybe need the following wget-configuration in your file `~/.wgetrc':
# Define your proxies (where 8080 and 8081 are examples # for the port-numbers) http_proxy = http://your.proxy.com:8080 ftp_proxy = http://your.ftpproxy.com:8081 # If you do not want to use proxy at all, set this to off. use_proxy = on |
If these requirements are satisfied you can download and install both ECB itself and also the required versions of semantic, eieio and speedbar:
ecb-download-ecb
:
A description for this command you will find in 4.14 Interactive ECB commands. Check also the options of the customize-group 'ecb-download' (see section 5.3.12 Group ecb-download).
ECB checks at load-time if the packages semantic, eieio and speedbar are at least installed and at start-time if the required versions of semantic, eieio and speedbar (see `README') are installed and loaded into Emacs. If not you will be asked if you want auto. download and install them. If you confirm this then ECB does the following:
ecb-download-package-version-type
you can specify which type of
versions (only stable, stable and betas or stable, betas and alphas)
you allow to download and install. This option offers also the choice
of asking you for a certain version. Depending of this setting ECB
either ask you which version it should download and install or chooses
autom. the newest version available which is matching both its
min-max-requirements and the setting in
ecb-download-package-version-type
.
NOTE: Currently there are only beta-versions of speedbar available therefore this option has to be set to 1 (allow stable and beta versions). But the speedbar beta-versions are very stable!
ecb-download-install-parent-dir
.
If both of these actions succeed then you will get a message-buffer which tells you something like:
-----------------------------------------------------------------
Current state of the required packages semantic, eieio, speedbar:
- semantic author-version must be [1.4, 1.4.9]:
Installed in /usr/local/lib/site-lisp/semantic-1.4
- eieio author-version must be [0.17, 0.17.9]:
Correct version already loaded!
- speedbar author-version must be [0.14beta1, 0.15.9]:
Correct version already loaded!
After adding the new directory to your |
Remark 1: "P author-version must be [x y]" means, that ECB requires package P in a version-number >= x and <= y.
Remark 2: By setting the option ecb-version-check
to
nil
you can prevent ECB from checking correct versions of
semantic, eieio and speedbar but it's strongly recommended not to do
this!
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
7.2.1 User interface for option-upgrading | Options and commands you should know | |
7.2.2 Background information | Maybe some interesting informations |
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are two interactive commands (see section 4.14 Interactive ECB commands):
ecb-upgrade-options
:
Does all necessary beginning with a incompatibility-check for all
options, upgrading/resetting incompatible options and ending with the
display of all upgraded or reset options.
ecb-display-upgraded-options
:
Displays an information-buffer which options have been upgraded or
reset. Offers two buttons where the user can decide if the upgraded
options should also being saved by ECB for future settings or if the
buffer should be killed.
If the option ecb-auto-compatibility-check
has a non-nil value
(which is the default) then ECB does all this stuff automatically at
startup. This is very recommended!
If you are interested in some background information, read 7.2.2 Background information!
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Big packages like ECB will be enhanced and developed continuously so sometimes a new version must be released. Such packages offer in general a lot of customizable options so probably some of these options change the type or are renamed because the old type and/or name of the option makes no sense in the new release.
Especially options which have changed the type of their value are now a problem for the user which want to upgrade to the latest ECB-version: If the user has saved a certain value for option X in its file `.emacs' but the type of this saved value doesn't match the new defined type in the defcustom-form after an ECB-upgrade then there can occur serious problems like ECB can not be started anymore or even Emacs can not be started without errors.
Until now there was only one way to fix these problems: The user must manually edit his file `.emacs' and remove all entries for options which have now another type. After this and after restarting Emacs the new default-values of the type-changed options in the new ECB-release are active and the user can go on using Emacs and ECB. But this approach to fix the incompatible-option-problem has two serious drawbacks:
OK, this is one half of the option-upgrade-problem but a new ECB-release can also rename a option from name X to name Y because the new name Y makes much more sense and/or is more mnemonic. If only the name has changed but not the type this is not a serious problem like above but also annoying because the customized value of the old-option X takes no effect in the new release but instead the default-value of the new-option Y is now active. But nevertheless this problem has the drawback number 2 (see above).
The last category of upgrade-problems is a renamed option which has also changed its type.
ECB has a solution for all these problems:
ecb-upgradable-option-alist
which
allows the ECB-maintainers to define special transformings for renamed
options so even the value of an old-option X can be savely transformed
to the new-option Y and the old setting is not lost.
All these checks and transformings are done at beginning of activating
ECB - if the option ecb-auto-compatibility-check
is not nil. If
ECB has recognized incompatible or renamed options it does its
upgrading/reseting-job so all ECB-options have correct types so ECB
can start correct. After ECB is started it displays a list of all
upgraded or reseted option with their old and new values.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by XEmacs shared group account on December, 19 2009
using texi2html 1.65.