Re: [Chicken-users] chicken-setup

[Ivan Raikov]

  Okay, so then let me repeat my previous proposal. As long as we can
agree on something, I can implement some initial prototype that can be
extended until the results are satisfying.

  What I would like to see is a two-tier installation system that
consists of an interpreter for compilation/installation scripts, and a
chicken-setup frontend. The interpreter should know three things:
where to get source tarballs (source locations), rules that specify
how to compile sources into executables, and where to install files
(installation locations). The frontend would read in an egg
specification (.meta file) supplant it with defaults such as source
locations, and provide a complete installation specification to the
interpreter.

   For example, suppose you had the following egg specification:

(;; meta properties from the current chicken-setup
 (egg "treap.egg") 
 (files "treap.scm" "treap-eggdoc.scm" "treap.setup" "tests/run.scm")
 (license "GPL-3")
 (category data)
 (needs testeez)
 (author "Oleg Kiselyov; packaged for Chicken Scheme by Ivan Raikov")
 (synopsis "A sorted dictionary data structure based on randomized 
            search trees.")
  
 ;; shared library specification
 (library treap
   (version 1.4)
   (make (treap.scm) (compile -O2 -d0 -s treap.scm -ldl -lchicken))))

The chicken-setup frontend would contain a list of default locations
where it could fetch the source for the egg; for compatibility with
the current chicken-setup, this list of default source locations could
be the current directory, the downloads directory, and
ftp.call/cc.org. Of course, these defaults could be overridden by the
user (for example to fetch source from svn).

   The frontend would also have a list of default installation
locations for each type of file (library, program, etc.). Using these
defaults, the frontend could for example generate the following
installation script:


 ((source-locations "."  "/home/user/tmp/chicken-4-user-downloads"
                    "ftp://call/cc.org/eggs/4";)
  (installation-locations ((library "/usr/lib/chicken/4")
                           (program "/usr/bin/")
                           (doc     "/usr/share/doc")))
  (library treap
           (make (treap.scm) ;; source files
                 (compile -O2 -d0 -s treap.scm -ldl -lchicken)))) 
                 ;; compilation commands

This specification would be passed to the interpreter, along with
commands such as "compile" "install" "uninstall", etc. 

   The idea is basically to isolate all of the general procedures for
e.g. installation and compilation, which once written would probably
stay relatively unchanged, and only modify the frontend as
chicken-setup policies evolve. We could also think about having
different frontends, e.g. for use with different package building
tools. 

   -Ivan

 
"felix winkelmann" <address@hidden> writes:

> Perhaps I'm just misunderstanding your intentions. I'd say `chicken-setup'
> already is a package-management tool in its current incarnation.
> I also don't want to start an argument about it. The current implementation
> has accumulated many features that make it (IMHO) hard to change
> and maintain. I just want to avoid that in the future.
>
> Great! Perhaps we can find someone who is willing to implement
> the low-level layer.