Re: [Rudel-devel] Repositories and install process

[Jan M. <sc...@gm...>]

On Thu, 2009-09-24 at 21:07 -0700, Phil Hagelberg wrote:
> Jan Moringen <sc...@gm...> writes:
> 
> > I just tried the following:
> >
> > cd /tmp
> > bzr branch bzr://rudel.bzr.sourceforge.net/bzrroot/rudel/trunk
> >
> > Then I evaluated the following code in an Emacs started with --no-init:
> >
> > (add-to-list 'load-path "/tmp/trunk")
> > (add-to-list 'load-path "/tmp/trunk/jupiter")
> > (add-to-list 'load-path "/tmp/trunk/obby")
> > (let ((generated-autoload-file "/tmp/trunk/loaddefs.el"))
> >        (update-directory-autoloads "/tmp/trunk/rudel/"))
> >  
> >      (byte-recompile-directory "/tmp/trunk/" 0)
> >
> > And it worked. Did you try something different? 
> >
> > I also committed some (unrelated) changes. Maybe one of it fixed the
> > problem?
> 
> No, that's quite right. What I meant was that you don't need CEDET at
> all to write autoloads and compile. 

Understood.

> So perhaps the hardcoded CEDET path
> could be removed from the makefile in favour of using standard built-in
> Emacs functions.

The Makefiles are auto-generated by EDE (part of CEDET). The best
solution may be to remove them from the repository and only use them in
working copies.

> What about using the attached install.el file instead?

Looks easy enough. `byte-recompile-directory', if I remember correctly,
works recursively, so there's no need to loop over subdirectories.

Also, I would prefer to separate the installation code and the
instructions that go with it. In my opinion, the INSTALL file should be
updated instead to refer to install.el.

Would you like to implement these changes in a bzr branch?

> >> Ideally we could bundle this up for install using ELPA,
> >> (http://tromey.com/elpa) which would make it absolutely trivial for new
> >> users to get started. It sets up autoloads and performs byte-compilation
> >> upon installation. 
> >
> > That would make things easier for users. However, for multi-file
> > packages, a special treatment seems to be necessary:
> > http://tromey.com/elpa/upload.html
> 
> Yes, I've talked with the elpa maintainer, and it turns out this is not
> really too big of a deal. If we can solve the other stability issues I'm
> seeing, I'd be glad to handle this myself.

Sure. It's not like you need my permission or something. I don't have
much experience with ELPA, and honestly am a bit skeptical towards the
one-file-per-package-is-the-default approach, but a packaging system is
definitely needed.

Jan