[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ams-pers-scheme-0.01
From: |
Thien-Thi Nguyen |
Subject: |
Re: ams-pers-scheme-0.01 |
Date: |
Wed, 26 Dec 2001 15:52:52 -0800 |
From: Alex Shinn <address@hidden>
Date: 26 Dec 2001 10:03:50 +0900
Nice... I'm considering it now. But we also need to distinguish
between modules and packages, and allow for manually setting the
dependencies by the author. Probably something like the Debian
share-lib dependencies check - the author of a package should
manually specify a list of package (not module) dependencies, one of
which could be the meta-package `auto'. If present, we run the
package's .scm files through use2dot, and lookup the modules there in
currently known packages to find additional dependencies.
But am I the only person thinking this shouldn't be Guile-specific?
Maybe that's too hard a goal, but it would be really nice if all the
different Scheme implementations had access to the same Scheme
repository, with packages marked as to which Schemes they work with.
At first, most packages would only work with their native Scheme, but
the existence of gumm might encourage some standardization and
consolidation of efforts.
i'm not so optimistic, but wouldn't mind seeing this happen.
in any case, autoconf-based methodology encourages thinking about
"features" instead of either "package" or "module". a package or module
might only provide one feature, thus its existence on the system could
be viewed synonymously, but this is not true generally. it is also not
true that versioning schemes have a universl algorithmic correlation w/
feature set, which is why i'd like to avoid that approach.
(disclaimer: ttn-pers-scheme looks for "guile-1.5.x" instead of its
features, which is a Bad Practice that will be changed soon. also,
there is some talk about module versioning schemes in guile-devel which
i'd like to argue against but don't have the energy.)
so, i'm revising my wish for autoconf support for modules. in a similar
way that a "library feature" is checked for by compiling a program that
links against the library and uses the particular feature, "module
feature" support should be tested by loading the module into a guile
interpreter and using it in some way.
to be more concrete, for module (SOME MODULE), load it into
`(guile-user)', and eval thunk FEATURE-TEST. set shell vars based on
result, etc. in the case where the module's feature can be adequately
surmised by its mere loading, FEATURE-TEST would be `(lambda () #t)':
AC_GUILE_MODULE_CHECK(var,(ams uri),(lambda () 1))
below is some experimental implementation. i can't get the
AC_MSG_RESULT to print correctly, though. also, using "#t" causes
problems since "#" is a the shell comment char. autoconf/shell wizards
please help!
thi
____________________________________________________________
# AC_GUILE_MODULE_CHECK(var,module,featuretest,description)
# - var is a shell variable name
# - module is a list of symbols, like: (ice-9 common-list)
# - featuretest is a thunk, like: (lambda () BODY ...)
# use "#t" for BODY for modules whose availability is the feature
# - description is some noun-phrase of the feature
#
AC_DEFUN([AC_GUILE_MODULE_CHECK],
[AC_MSG_CHECKING([$2 $4])
$1=no
echo '(use-modules $2) (exit ($3))' > conftest
guile -s conftest > /dev/null 2>&1 && $1=yes
rm -f conftest
AC_MSG_RESULT($[$1])
])
AC_DEFUN([AC_GUILE_MODULE_AVAILABLE],
[AC_GUILE_MODULE_CHECK($1,$2,(lambda () 1),availability)])