Re: Any New Guile Release Planned ?

[Ludovic Courtès]

Vladimir Zhbanov <address@hidden> skribis:

> On Tue, Oct 27, 2015 at 06:54:44PM +0100, Ludovic Courtès wrote:
>> Rafik NACCACHE <address@hidden> skribis:
>> 
>> > Is there any new release planned soon?
>> 
>> We’ve been meaning to release 2.0.12, which is mostly bug fixes.
>
> The stable-2.0 guile branch contains changes that some of our users
> (that is, users of gEDA/gaf) have been waiting for years, especially
> after guile 2.0 became necessary to build our package. I mean those
> users who have been waiting for Windows support. (Some of them insist on
> moving to using Python instead of Guile these days, since they have been
> tired trying to cross-compile with guile-2.0 support.) A while ago I was
> eventually able to build our toolkit using only one patch for guile [1]
> (almost one-liner, in essence), and several work-around patches for some
> of our programs, which can be found at [2] and are actually the same
> code blocks (declaring an array and doing its initialisation). I don't
> know why the latter patches work (geda-gaf with guile 1.8 worked without
> them), however, I am sure the issue is in guile 2.0, though I cannot
> even found the culprit by bisecting (because of too many changes in both
> guile and geda-gaf repositories). Having said all that, I'd like to see
> at least the patch [1] committed before the next guile release in order
> to have guile cross-compilation for windows working. Are there any
> chances for that?

Sure, we’ll do our best.

> [1] 
> https://github.com/vzh/minipack/blob/master/patches/guile/0001-MinGW-build-support.patch

Could you explain the details?  An excerpt of the build log when
cross-compiling to MinGW without the patch would be great.

The reason I ask is that we rely on Gnulib for these portability
things.  The <sys/select.h> in libguile/iselect.h is supposed to do the
right thing; if it’s not, we should (1) update our Gnulib copy, and (2)
fix the problem in Gnulib if it’s still there.

Thanks,
Ludo’.