bug#7995: Guile support in Automake

[Andy Wingo]

Ralf, you are a hero.

On Sun 20 Feb 2011 08:30, Ralf Wildenhues <address@hidden> writes:

> So what I would like to ask from readers at this point is:
> please go through the doc changes and let's discuss them first.

Will reply to that patch.

> Also, it is important to not step on guile/meta/guile.m4 toes (or vice
> versa), so some checking for that is prodent.  When we know what is
> desired, the tests should be amended/fixed to cover that, and then we
> can fix the implementation to follow.

What would it mean for AM_PATH_GUILE to step on guile.m4's toes?

FWIW guile.m4 almost never gets updates, but today was one of those
exceptions:

  
http://git.savannah.gnu.org/cgit/guile.git/commit/?h=stable-2.0&id=1867d3e0195168a34cf2269c2137ac561d03a252

Basically it's something from Bruno to add GUILE_LIBS as opposed to
GUILE_LTLIBS, getting the rpath stuff right.

Later you say:

> - The Guile manual documents Autoconf macros distributed in
>   $datarootdir/aclocal/guile.m4.  The names in there are a bit
>   unfortunate in that the macros more or less use the same GUILE_*
>   namespace that we would like to use for some variables (which means
>   you cannot easily turn on checking for unexpanded macro names through
>   something like
>     m4_pattern_forbid([^GUILE_])dnl
>
>   and there is even overlap in the semantics and shell variable names.
>   We need to address that; esp. since the macros shipped with Guile have
>   been out there for long, we cannot just expect them to disappear
>   instantly.  There should be a clear, backward-compatible upgrade path,
>   and a clear intent on how usage should be in the future, for Guile
>   users both with and without Automake.

Hmmm.

So guile.m4 defines the following macros:

    GUILE_PROGS
    GUILE_FLAGS
    GUILE_SITE_DIR
    GUILE_CHECK
    GUILE_MODULE_CHECK
    GUILE_MODULE_AVAILABLE
    GUILE_MODULE_REQUIRED
    GUILE_MODULE_EXPORTS
    GUILE_MODULE_REQUIRED_EXPORT

Of these, only the first three do any AC_SUBST operations; so we can
safely say the rest don't affect this discussion, no?

GUILE_PROGS does this:

      AC_SUBST(GUILE)
      AC_SUBST(GUILE_CONFIG)
      AC_SUBST(GUILE_TOOLS)

Here AM_PATH_GUILE also defines GUILE_TOOLS, but it does the same
AC_PATH_PROG check for it, so calling both macros should not present a
problem.

GUILE_SITE_DIR only defines GUILE_SITE, so that doesn't conflict.

GUILE_FLAGS is the only one that's tricky.  It defines:

  AC_SUBST([GUILE_CFLAGS])
  AC_SUBST([GUILE_LDFLAGS])
  AC_SUBST([GUILE_LIBS])
  AC_SUBST([GUILE_LTLIBS])

These are all for compiling C code.  Ideally one would not even have to
check for these if you're not compiling C extensions.  Is that possible?
In any case these variables' definitions should be exactly the same as
those that GUILE_FLAGS defines; though it is tough to ensure that a
"guile-config compile" or "pkg-config --cflags guile-2.0" corresponds to
the "guile-tools compile" output.  Hummm.

> If you prefer, I can also put them in a temporary branch (which for the
> moment I would expect to be rewound at some point later).

Please do, if it's not very much trouble.

> - Why guile_GUILE and not guile_LISP?  What's the rationale for naming
>   it differently, and what's the rationale for actually treating it
>   differently?  This question has two parts: LISP is treated by emacs
>   not guile-tools, and IIUC then the idea was that GUILE is compiled
>   already at 'make all' time and not just at 'make install' time, right?
>   Is the latter part just "nice to have" or an important feature?

I think that it is useful to compile at "make all" time, yes.  You can
run programs uninstalled in many cases, with an environment that picks
up the compiled ".go" files from the uninstalled tree.  Compiling can
also show warnings -- of course if it doesn't compile at all, that's
useful to know; but furthermore there are the -W warnings.

> - The current tests assume _GUILE sources are distributed by default;
>   OTOH, _LISP are not.  Rationale for this semantic difference?

It seems more useful.  I don't see any particular affinity between Guile
and Elisp, by the way; we might as well compare to Python, which does
dist by default.

> - I renamed guileextensiondir from earlier suggestions to guileextdir,
>   both for brevity, and to avoid the question of whether there is a
>   trailing 's' in the name.  OK?

Sounds good.

> - I haven't yet considered the handling of flags to uninstalled module
>   stuff.  This is just TODO.

Yeah, indeed.

> - My current plan is to either not provide something like
>     foo_scm_GUILEFLAGS = override for $(AM_GUILEFLAGS)
>
>   or to not let it cause renamed .go files.  Do you think users will
>   need per-target guile-tools compile flags?  Because if they do, then
>   we need to document this stuff, and that it's not in line with how
>   Automake operates elsewhere, etc.

I think we would be fine without per-target compile flags.

Regards,

Andy
-- 
http://wingolog.org/