non standard name of a dependency

[Catonano]

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
checking for guile... /usr/bin/guile
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

How can I build guile-commonmark against guile 2.2.2 ?

Is this a task for the package author ?

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

Thanks in advance

[Bob Friesenhahn]

Post by Catonano
How can I build guile-commonmark against guile 2.2.2 ?
Is this a task for the package author ?
Or can I instruct the build system somehow about which guile to use ?

This depends on how the configure script is searching for guile. If
it is using pkg-config, then you may need to set the PKG_CONFIG_PATH
environment variable to find the pkg-config file for this package.
If it is using PATH, then you should make sure that /usr/bin/guile2.2
is in your path prior to the default system version.

For example:

export PATH=/usr/bin/guile2.2:$PATH
./configure

Bob

[Eric Blake]

Post by Catonano
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?

Post by Catonano
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.

Post by Catonano
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.

Post by Catonano
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).

Post by Catonano
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.

[Catonano]

Post by Eric Blake

Post by Catonano
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?

Post by Catonano
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
./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

Post by Eric Blake
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

Post by Eric Blake
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