H...
I think having to name all the systems differently in each branch is a
poor methodology and likely to lead to confusion over time. Instead,
I wrote a simple shell script to change .asd symbolic links in my
system directory.
We might bundle a shell script and batch file that one
Thanks Robert.
I'll look into it. I was thinking of something much simpler than you
outlined. Rather than trying to support reading objects across
versions, I was just looking to support two different versions of the
elephant packages, and to tease out the load-op dependencies that
refer
I'm not a master of anything, but pragmas seem to be the approach used in
hunchentoot (see below).
(asdf:defsystem :hunchentoot
:serial t
:version #.*hunchentoot-version*
:depends-on (:chunga
:cl-base64
:cl-fad
:cl-ppcre
#-(or :li
On Sun, 2008-05-11 at 14:22 -0700, Bryan Emrys wrote:
> At one point the clbuild maintainers looked at elephant but had some problems
> that prevented inclusion.
>
> Specifically:
>
> # - needs sb-posix, but doesn't declare that dependency, meaning that
> #it doesn't build even with a confi
On Sun, 2008-05-11 at 19:50 -0400, Glenn Tarcea wrote:
> What do you all think about allowing two different versions of
> Elephant to be installed at the same time? I tried to have both my
> original version of Elephant installed and also to install elephant-
> unstable. Currently there are a
What do you all think about allowing two different versions of
Elephant to be installed at the same time? I tried to have both my
original version of Elephant installed and also to install elephant-
unstable. Currently there are a lot of dependencies on the system
name sprinkled throughout
At one point the clbuild maintainers looked at elephant but had some problems
that prevented inclusion.
Specifically:
# - needs sb-posix, but doesn't declare that dependency, meaning that
#it doesn't build even with a config file
# - ele-clsql loads clsql from the .asd file, not using :dep
