Content preview: On 28 Jun 2011, at 19:52, Faré wrote: > On 28 June 2011 13:38,
Pascal Costanza <pc-***@public.gmane.org> wrote: >> >> On 28 Jun 2011, at 17:49, Zach
Beane wrote: >> >>> Faré <fahree-***@public.gmane.org> writes: >>> >>>>> I am looking
for a portable way to specify configuration for a library >>>>> before/during
loading with ASDF2. It would be sufficient if the user >>>>> could specify
an ALIST (or something similar) somewhere and I could read/ >>>>> use it
when the library is loaded. Does ASDF2 have a "standard" >>>>> mechanism for
library config files (eg where they are, how to handle them >>>>> etc), or
should I use something else? I thought of using *features*, but >>>>> I need
actual values instead of merely checking for the presence of >>>>> symbols.
do. >>> >>> The question is not about C libraries, but how to express and
manage >>> configuration options that must be initialized before the library
is >>> built. >>> >>> I think the answer for ASDF is "there is no way to
express or manage any >>> library configuration decisions." >>> >>> Hunchentoot
also has this issue regarding building with SSL, and manages >>> it by checking
for :hunchentoot-no-ssl in cl:*features*. For a >>> non-boolean option, that's
not a workable approach. >> >> One could use a global variable that stores
one's own configuration option, for example as a plist or alist. This would
have to be in the common-lisp-user package, and theoretically clashes with
other such variables. However, this is not substantially worse than potential
clashes of keyword symbols in *features*. Just use a name that is unlikely
to be used by others (for example, by using the ASDF/package name with an
-OPTIONS suffix, or some such). >> >> boundp is your friend to check whether
the variable is actually defined, which could either yield a warning, or
assume default options. >> >> Pascal >> > What's so special about Lisp here?
How do other languages do it? > > If it's about libraries that are shared
by everyone using the standard > C ABI, then [...]
Content analysis details: (-102.3 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[134.184.129.112 listed in list.dnswl.org]
X-BeenThere: pro-***@public.gmane.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Common Lisp Professionals <pro.common-lisp.net>
List-Unsubscribe: <http://lists.common-lisp.net/cgi-bin/mailman/options/pro>,
<mailto:pro-request-***@public.gmane.org?subject=unsubscribe>
List-Archive: <http://lists.common-lisp.net/pipermail/pro>
List-Post: <mailto:pro-***@public.gmane.org>
List-Help: <mailto:pro-request-***@public.gmane.org?subject=help>
List-Subscribe: <http://lists.common-lisp.net/cgi-bin/mailman/listinfo/pro>,
<mailto:pro-request-***@public.gmane.org?subject=subscribe>
Errors-To: pro-bounces-***@public.gmane.org
X-Spam-Score: -100.3 (---------------------------------------------------)
X-Spam-Report: Spam detection software, running on the system "common-lisp.net", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: On 28 Jun 2011, at 19:52, Faré wrote: > On 28 June 2011 13:38,
Pascal Costanza <pc-***@public.gmane.org> wrote: >> >> On 28 Jun 2011, at 17:49, Zach
Beane wrote: >> >>> Faré <fahree-***@public.gmane.org> writes: >>> >>>>> I am looking
for a portable way to specify configuration for a library >>>>> before/during
loading with ASDF2. It would be sufficient if the user >>>>> could specify
an ALIST (or something similar) somewhere and I could read/ >>>>> use it
when the library is loaded. Does ASDF2 have a "standard" >>>>> mechanism for
library config files (eg where they are, how to handle them >>>>> etc), or
should I use something else? I thought of using *features*, but >>>>> I need
actual values instead of merely checking for the presence of >>>>> symbols.
do. >>> >>> The question is not about C libraries, but how to express and
manage >>> configuration options that must be initialized before the library
is >>> built. >>> >>> I think the answer for ASDF is "there is no way to
express or manage any >>> library configuration decisions." >>> >>> Hunchentoot
also has this issue regarding building with SSL, and manages >>> it by checking
for :hunchentoot-no-ssl in cl:*features*. For a >>> non-boolean option, that's
not a workable approach. >> >> One could use a global variable that stores
one's own configuration option, for example as a plist or alist. This would
have to be in the common-lisp-user package, and theoretically clashes with
other such variables. However, this is not substantially worse than potential
clashes of keyword symbols in *features*. Just use a name that is unlikely
to be used by others (for example, by using the ASDF/package name with an
-OPTIONS suffix, or some such). >> >> boundp is your friend to check whether
the variable is actually defined, which could either yield a warning, or
assume default options. >> >> Pascal >> > What's so special about Lisp here?
How do other languages do it? > > If it's about libraries that are shared
by everyone using the standard > C ABI, then [...]
Content analysis details: (-100.3 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-100 USER_IN_WHITELIST From: address is in the user's white-list
2.0 SINGLE_HEADER_2K A single header contains 2K-3K characters
-2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/, medium
trust
[134.184.129.112 listed in list.dnswl.org]
Archived-At: <http://permalink.gmane.org/gmane.lisp.cl-pro/474>
Post by FaréPost by Pascal CostanzaPost by Zach BeanePost by FaréPost by Tamas PappI am looking for a portable way to specify configuration for a library
before/during loading with ASDF2. It would be sufficient if the user
could specify an ALIST (or something similar) somewhere and I could read/
use it when the library is loaded. Does ASDF2 have a "standard"
mechanism for library config files (eg where they are, how to handle them
etc), or should I use something else? I thought of using *features*, but
I need actual values instead of merely checking for the presence of
symbols.
ASDF (1 or 2) does not handle C libraries. Extensions to ASDF do.
The question is not about C libraries, but how to express and manage
configuration options that must be initialized before the library is
built.
I think the answer for ASDF is "there is no way to express or manage any
library configuration decisions."
Hunchentoot also has this issue regarding building with SSL, and manages
it by checking for :hunchentoot-no-ssl in cl:*features*. For a
non-boolean option, that's not a workable approach.
One could use a global variable that stores one's own configuration option, for example as a plist or alist. This would have to be in the common-lisp-user package, and theoretically clashes with other such variables. However, this is not substantially worse than potential clashes of keyword symbols in *features*. Just use a name that is unlikely to be used by others (for example, by using the ASDF/package name with an -OPTIONS suffix, or some such).
boundp is your friend to check whether the variable is actually defined, which could either yield a warning, or assume default options.
Pascal
What's so special about Lisp here? How do other languages do it?
If it's about libraries that are shared by everyone using the standard
C ABI, then shouldn't it all "just work", using the LD_LIBRARY_PATH
and other standard configuration files, and/or paths wired into your
object files?
If it's about wrapper libraries created by cffi-grovel, then ASDF will
load them from wherever the fasl cache is defined. This doesn't play
very well with distribution of binaries (as opposed to distribution of
source), but at least it should "do the right thing", and the basic
configuration knobs are there if you want to do better.
Or maybe what you want is some way to specify C compiler flags for
cffi-grovel? This is currently done through the
cffi-grovel::*cc-flags* special variable.
Now, if you want to somehow have per-user configuration, overridable
with an environment variable and/or an explicit programmer parameter,
I recommend that you use the same conventions as currently used by
ASDF 2 and read configuration from a file in the same directory. You
may copy/paste code from ASDF 2, and/or I will happily refactor the
code so that it may be used by ASDF extensions as well as by ASDF
itself.
Configuration files are for languages where there is a strong distinction between programs and data. Lisp doesn't need no stinking configuration files. ;)
You may want configuration options that change which parts of your code are read and how, and how certain macros are expanded. Such configuration options need to be specified before code is read or macro-expanded.
Pascal
--
Pascal Costanza
The views expressed in this email are my own, and not those of my employer.