Sven Joachim writes:
> Probably emacs-install would need to be changed to take package
> dependencies into account, but the emacsen-common package does not
> seem to be maintained currently.
Depending on what you mean, emacs-install does take package
dependencies into account. See generate-inst
On Wed, Aug 06, 2008 at 09:07:48AM -0700, Michael Olson wrote:
> Hilko Bengen <[EMAIL PROTECTED]> writes:
>
> > Michael Olson <[EMAIL PROTECTED]> writes:
> >
> >>> When semantic is installed or upgraded -- yes. But what happens when
> >>> $FLAVOR is upgraded?
> >>
> >> It ought to call emacs-remov
Hilko Bengen <[EMAIL PROTECTED]> writes:
> Michael Olson <[EMAIL PROTECTED]> writes:
>
>>> When semantic is installed or upgraded -- yes. But what happens when
>>> $FLAVOR is upgraded?
>>
>> It ought to call emacs-remove $FLAVOR, followed by emacs-install
>> $FLAVOR, which would recompile the Emac
Michael Olson <[EMAIL PROTECTED]> writes:
>> When semantic is installed or upgraded -- yes. But what happens when
>> $FLAVOR is upgraded?
>
> It ought to call emacs-remove $FLAVOR, followed by emacs-install
> $FLAVOR, which would recompile the Emacs Lisp packages in a
> dependency-first manner.
I
Hilko Bengen <[EMAIL PROTECTED]> writes:
> Michael Olson <[EMAIL PROTECTED]> writes:
>>
>> Yes, it's what I want. I didn't use quite the correct description
>> earlier -- it's the Emacs-version-specific directory that should be
>> included in load-path, not the sources. The configuration scripts
>
Michael Olson <[EMAIL PROTECTED]> writes:
> Hilko Bengen <[EMAIL PROTECTED]> writes:
>
>> Michael Olson <[EMAIL PROTECTED]> writes:
>>
>>> I've implemented this as follows for the semantic package.
>>
>>> [...]
>>
>>> cat << EOF > path.el
>>> (let ((paths (list "${ELPREFIX}" "${ELPREFIX}/bovin
Hilko Bengen <[EMAIL PROTECTED]> writes:
> Michael Olson <[EMAIL PROTECTED]> writes:
>
>> I've implemented this as follows for the semantic package.
>
>> [...]
>
>> cat << EOF > path.el
>> (let ((paths (list "${ELPREFIX}" "${ELPREFIX}/bovine" "${ELPREFIX}/wisent"
>>"/usr/sh
Michael Olson <[EMAIL PROTECTED]> writes:
> I think it's a good policy to add the source directories for all
> Emacs Lisp packages that are depended upon while performing
> byte-compilation,
Agreed.
> and to inhibit the loading of site-start.el. This prevents any 3rd
> party packages from inter
Hilko Bengen <[EMAIL PROTECTED]> writes:
> My workaround consists of adding the source directory for w3m-el to
> the load-path when sepia is byte-compiled.
I think it's a good policy to add the source directories for all Emacs
Lisp packages that are depended upon while performing byte-compilation
Sven Joachim <[EMAIL PROTECTED]> writes:
> On 2008-07-26 23:00 +0200, Hilko Bengen wrote:
>> Source file `/usr/share/emacs22/site-lisp/sepia/snippet.el' newer than
>> byte-compiled file
>
> Not related to your problem, but this looks strange. Why does the
> byte-compiled file exist and why is the
On 2008-07-26 23:00 +0200, Hilko Bengen wrote:
> An emacs22 upgrade that was recently installed broke when it tried to
> byte-compile a part of sepia (for which I maintain the Debian
> package). This is the output I got when I tried to reinstall the
> emacs22-gtk package:
>
> $ sudo apt-get --rein
An emacs22 upgrade that was recently installed broke when it tried to
byte-compile a part of sepia (for which I maintain the Debian
package). This is the output I got when I tried to reinstall the
emacs22-gtk package:
$ sudo apt-get --reinstall install emacs22-gtk
[...]
emacs-install emacs22
insta
12 matches
Mail list logo
