Re: non standard name of a dependency

[Eric Blake]

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
./configure ac_cv_prog_guile=/usr/bin/guile2.2

You'll also want to file a bug report to the guile-commonmark package 
maintainers to have them improve their configure.ac if it isn't already 
easily overridable.

> configure: error: found development files for Guile 2.2, but /usr/bin/guile
> has effective version 2.0
>
> I'm afraid of removing guile 2.0.14 because it seems that an awful lot of
> stuff depends on it

No, you shouldn't need to remove it.

> How can I build guile-commonmark against guile 2.2.2 ?
>
> Is this a task for the package author ?

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

> Or can I instruct the build system somehow about which guile to use ?

Yes, that should be possible if the package followed the autoconf 
recommendations for allowing overrides.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org