Thanks for quick replies.

> Actually, this feature is already available, I believe, through the
> :HERE directive in the configuration language.
> 
> This was something we added for the case that I found common, where
> there would be a project directory tree, with all the required code in
> subdirectories, and a master configuration file at the root.*

It is a little bit different from what I wanted to do.
I'm trying to run a one-liner sbcl command with adding a specific directory to source registry.

Though CL_SOURCE_REGISTRY looks perfect for the purpose, it must be a string and doesn't accept relative pathnames.

# copying from my first email
# doesn't work
CL_SOURCE_REGISTRY=. sbcl --eval '(princ (asdf:system-source-directory :myapp))'

Of course, it can be done with --eval "(push #P"." asdf:*central-registry*)", but it's really verbose.
Is there another way to do it?

Cheers,
Eitaro

On Thu, Feb 19, 2015 at 11:55 AM, Robert P. Goldman <rpgoldman@sift.net> wrote:
Faré wrote:
> Isn't it allowed because it's never clear what directory they are
> relative to, considering that the user may have changed the getcwd()
> arbitrarily between startup and asdf parsing the source-registry
> configuration, which would cause "interesting" subtle bugs, that I
> wanted to avoid — including security issues if a binary written in
> Lisp ever loads systems at runtime and examines a carefully crafted
> directory.
>
> I suppose there's a case for allowing relative names, making them
> relative to the configuration file when in a configuration file
> (though that's not a common use case at all), and relative to
> *default-pathname-defaults* when in an environment string, leaving the
> user full responsibility to avoid subtle bugs. I'm not the one to
> convince anymore, though. Ask Robert. If he agrees with you, I'll
> gladly help with the required modifications to ASDF.

Actually, this feature is already available, I believe, through the
:HERE directive in the configuration language.

This was something we added for the case that I found common, where
there would be a project directory tree, with all the required code in
subdirectories, and a master configuration file at the root.*

Have a look at that and see if it does what you want.

Cheers,
r

* In practice, we create these trees by checking a project out from svn.
We'd have all the required libraries, in stable versions, included as
svn externals.