Re: non standard name of a dependency

[Catonano]

Il giorno ven 21 set 2018 alle ore 22:09 Eric Blake <address@hidden> ha
scritto:

> On 9/21/18 2:44 PM, Catonano wrote:
> > I don't know if this is the right place to ask. If it's not, I apologize
> >
> > I'd like to build guile-commonmark (
> > https://github.com/OrangeShark/guile-commonmark/ ) on Fedora 28
> >
> > I'd like to build it against guile 2.2.2
> >
> > On Fedora 28 x86_64 there are 2 versions  of Guile
> >
> > Guile 2.0.14
> >
> > and
> >
> > Guile 2.2.2
> >
> > Guile 2.0.14 is in /usr/bin/guile
> >
> > Guile 2.2.2 is in /usr/bin/guile2.2
> >
> > this is what happens
> >
> > ...
> > configure: checking for guile 2.2
> > configure: found guile 2.2
>
> What does config.log say it actually found?
>
> > checking for guile... /usr/bin/guile
>
> Wait? Why is configure checking twice? You'll need to investigate what
> the configure.ac for guile-commonmark is using, and why it is repeating
> two different checks for guile (one that found the right version,
> another that found the wrong one).  If that code in configure.ac uses a
> cache variable (${prefix}_cv_$...) and/or an environment variable
> (probably $GUILE) to encode the result of the guile binary, then the
> immediate workaround is to set that cache or environment variable as an
> argument to configure, so that when it gets to that particular check, it
> already has the answer you told it to use instead of the one it guesses
> from your environment.  If their configure.ac used
> AC_CHECK_PROGS([guile]), then both of these should work:
>
> ./configure GUILE=/usr/bin/guile2.2
>

This worked

The package author confirmed the issue and he has his reasons for not
fixing it

He suggested me to use this method for the guild command too

This allowed me to build guile-commonmark

After that I also built Haunt, a guile based static blogger. It depends on
guile-commonmark to parse markdown files and publish them as blog posts
(commonmark is a variant of markdown)

I expected similar issues from Haunt too, but instead it picked up the
right guile, guild, AND the guile-commonmark I had built, out of the box,
with no hint

Strange

Thanks for your help





>
> Autoconf recommends using cache variables (for overriding decisions that
> are otherwise guessed incorrectly from probing the system) and
> envrionment variables (for pointing to a specific version of a tool that
> you want to use), so this list is the appropriate place to ask about how
> those things work in general.


Ok, thanks


> However, whether those things were
> actually used correctly for the package in question is something for the
> package author to answer, according to their configure.ac, which
> autoconf does not maintain (although the package maintainer should feel
> free to continue this thread if they need help improving their
> configure.ac to match recommended best practices).
>

In fact, I will suggest to the guile-commonmark author to come here to ask
for help with the issues he has with the autotools setup for his package

Because if Haunt works correctly, that can be done

Thanks again