possible configure bug

possible configure bug

[Aidan Gauland]

I'm not sure whether this is a bug, but it's inconsistent behaviour.  I
ran (in the guile-2.0.9 directory)

 $ ./configure -C

and got an error about a missing dependency, which I installed, and then
and re-ran "./configure -C", which detected the newly installed
dependency and reported a *different* missing dependency.  I repeated
this a few times until it got to unistring, which it did not detect
after I installed it until I re-ran ./configure *without* -C.

I realise -C means "cache", but since the configure script detected the
other libraries when re-run with caching on, not detecting unistring is
an inconsistent behaviour, and I don't know much about autoconf (I've
only used straight make for my projects), so I don't know whether this
is a bug or merely unexpected behaviour.

I also realise that this is of ridiculously low importance compared to
what else the Guile devs are working on, so I'm marking this bug as
NITPICK. ;)

Regards,
Aidan Gauland

Re: possible configure bug

[Ludovic Courtès]

Aidan Gauland <aidalgol@no8wireless.co.nz> skribis:

> I'm not sure whether this is a bug, but it's inconsistent behaviour.  I
> ran (in the guile-2.0.9 directory)
>
>  $ ./configure -C
>
> and got an error about a missing dependency, which I installed, and then
> and re-ran "./configure -C", which detected the newly installed
> dependency and reported a *different* missing dependency.  I repeated
> this a few times until it got to unistring, which it did not detect
> after I installed it until I re-ran ./configure *without* -C.

Which dependency exactly?

Normally info related to dependencies whose unavailability leads to an
error (such as libunistring and bdw-gc) is *not* cached.

Thanks,
Ludo’.

Re: possible configure bug

[Aidan Gauland]

ludo@gnu.org (Ludovic Courtès) writes:

> Aidan Gauland <aidalgol@no8wireless.co.nz> skribis:
>
>> I'm not sure whether this is a bug, but it's inconsistent behaviour.  I
>> ran (in the guile-2.0.9 directory)
>>
>>  $ ./configure -C
>>
>> and got an error about a missing dependency, which I installed, and then
>> and re-ran "./configure -C", which detected the newly installed
>> dependency and reported a *different* missing dependency.  I repeated
>> this a few times until it got to unistring, which it did not detect
>> after I installed it until I re-ran ./configure *without* -C.
>
> Which dependency exactly?
>
> Normally info related to dependencies whose unavailability leads to an
> error (such as libunistring and bdw-gc) is *not* cached.

It got stuck on libunistring.

The previous missing dependencies that it *did* detect after I installed
them were libffi, libgc (the Debian package name for bdw-gc), and
libgmp (in that order).

Re: possible configure bug

[Daniel Hartwig]

On 23 June 2013 21:47, Ludovic Courtès <ludo@gnu.org> wrote:
> Aidan Gauland <aidalgol@no8wireless.co.nz> skribis:
>
>> I'm not sure whether this is a bug, but it's inconsistent behaviour.  I
>> ran (in the guile-2.0.9 directory)
>>
>>  $ ./configure -C
>>
>> and got an error about a missing dependency, which I installed, and then
>> and re-ran "./configure -C", which detected the newly installed
>> dependency and reported a *different* missing dependency.  I repeated
>> this a few times until it got to unistring, which it did not detect
>> after I installed it until I re-ran ./configure *without* -C.
>
> Which dependency exactly?
>
> Normally info related to dependencies whose unavailability leads to an
> error (such as libunistring and bdw-gc) is *not* cached.
>

Perhaps, though in general if anything has changed in the dependencies
I would not be using ‘-C’ for cached responses.  Run all tests fresh
as there can be effects from inter-related dependencies that change.