> OK, I did that. It was much easier this time, probably because of
> your good work on fixing bugs, and also because I'm much more
> experienced now with MSYS.
Great! And thanks a lot for your timely testing.
> 1. Compilation of font.cpp fails:
>
> [...]
> I fixed this by adding
>
> #include "../config.h"
>
> to the beginning of gnulib's wctype.in.h. This kludge works, but
> it really isn't something I suggest as _the_ solution for this
> problem; I don't really know enough gnulib to suggest something
> better.
Actually, it is *the* solution right now, and now in the git
repository :-) After this release we are going to switch to an
automake build system for the whole package, with gnulib included in
the correct way – we then no longer need this hack.
> 2. Error messages in font/devpdf:
>
> Warning: line 28: Unable to locate font(s)
> URWGothicL-Demi,a010015l.pfb on the given path(s)
> [...]
>
> I guess these are expected, since I don't have Ghostscript
> installed?
Yes. Again, we should handle this in a better way as soon as we have
a new build system.
> 3. Error in doc/:
>
> [...]
>
> preconv: encoding system `CP1252' not supported
OK. This essentially means that libiconv is absolutely necessary for
Windows. This is something I hadn't thought of.
> This is because the configure script fails to detect libiconv:
> [...]
This seems to be a gnulib bug. Looking into file `iconv.m4' (which is
the most recent one), I see that in `gl_iconv_AC_DEFUN' the macro
`AM_ICONV_LINK' is called before the test that checks whether `const'
is needed. Obviously, it should be the opposite...
I'll report it upstream.
> 4.-7. [...]
I think that all those issues will be automatically vanish after the
switch to a full automake infrastructure.
> 7. Finally, I made *.cmd batch files for most Perl and shell scripts
> installed in bin/, since otherwise those scripts will be almost
> unusable from the native Windows shell. Would you accept those
> batch files for inclusion in Groff, and add them to "make install"
> on Windows? Most of the batch files are simple one-liners, to
> invoke Perl on the respective script.
Yes, please send them to the list, together with changes to the
Makefile(s) if necessary.
Werner
