Re: ams-pers-scheme-0.01

[Thien-Thi Nguyen]

   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)])