normal execution and rc files

[russell]

Hey,

During a build of stumpwm we currently require that the use have a working quicklisp environment if they want the build to succeed. So when make calls /usr/local/bin/sbcl it makes the assumption that the users RC file will initialise ASDF and Quicklisp if they are needed.

We have been using cl-travis quite successfully but since moving to CIM we have struggled to get the build working again.

Currently if we initialise an environment with cim e.g.

cl -l clx -l cl-ppcre -Q

The environment doesn't exist at runtime for any lisp distribution that is called directly (i.e not with the cl executable). This seems to be because only the cim executables actually init themselves with ~/.cim/init.lisp.

Currently we call sbcl like this /usr/local/bin/sbcl --load ./make-image.lisp Is there some way that we should be calling sbcl/ccl/clisp that will also initialise the cim machinery and it's init.lisp file?

We are currently using this in our travis yml file to get things working.

  - echo "(load \"/home/travis/asdf\")" > "$HOME/.clisprc.lisp"
  - cl -l clx -l cl-ppcre -e '(ql-util:without-prompting (ql:add-to-init-file))'

Thanks!

[luismbo]

First off, sorry for breaking your build. I know how frustrating that can be. :-( Calling ~/.cim/bin/sbcl might work, but that's a bit annoying. I will probably symlink each Lisp's rc file to ~/.cim/init.lisp. I'll try that and get back to you.

[luismbo]

Meh, ~/.cim/init.lisp has dependencies on CIM internals, so loading that doesn't work. Off to plan B. :-)

[luismbo]

@russell OK, I think 3bc8d9c fixes your problem. Can you test it using cl-travis's develop branch or is it easier for you if I push it to master?

[russell]

Yes I can test from your development branch.

Works like a charm. Merge when ever you feel like it, i got the stumpwm build working so there is no rush. Thanks for fixing this!

Keep reading if you bored :-)

Also i did try and use the CIM builtin sbcl wrapper for a test but was really crazy crap. CIM uses 2 directories ~/.cim/bin contains sbcl-system and ~/.cim/scripts contains the sbcl script. So i was able to run the ./configure with the path modified to match ~/.cim/scripts to pick up the sbcl wrapper but then make needed the ~/.cim/bin directory when make was run so that it could find the sbcl-system binary. To further complicate things a config file needs to be read that is keyed to the PPID at which the install.sh script ran. I have included a copy of the yml file at the bottom. After all that it still wasn't reading the config file.

After reading the main CIM lisp file it looks to me like CIM is providing a unified CL CLI interface by implementing a common CLI in lisp. So it seems like CIM is doing more than just wrapping existing CL implementations with shell scripts. Instead it's a totally new CLI for all lisps.

language: lisp

env:
  global:
    - CIM_HOME="$HOME/.cim"
  matrix:
    - LISP=sbcl
    - LISP=ccl
    - LISP=clisp
    # - LISP=ecl

install:
  - sudo apt-get install texinfo
  - curl https://raw.githubusercontent.com/luismbo/cl-travis/master/install.sh | sh;
  - cl -l clx -l cl-ppcre -Q
  - ln -s $HOME/.cim/config/current.* $HOME/.cim/config/current.sentinel

before_script:
  - ./autogen.sh
  - PATH="$HOME/.cim/scripts:$PATH" ./configure

script:
  - CIM_ID="sentinel" PATH="$HOME/.cim/bin:$PATH" make

[luismbo]

Indeed, poking too much into CIM leads to trouble fast. :-) In the end, I really like the cl script, so it's worth it, I guess. Merging develop into master. Thanks!