Sun 16 Aug 2015 12:46:59 PM UTC, comment #1:
Ok, now I tried it with the activestate perl, but it seems that MSYS
autotools aren't able to manage it correctly, as I got the following:
So I edited manually tp/Texinfo/Convert/XSParagraph/lib/Makefile and
tp/Texinfo/Convert/XSParagraph/Makefile to replace
c:\NOS_PR~1\msys\MINGW-~1\I686-4~1.0-P\mingw32\bin\gcc.exe by gcc.
That made it go a little further, but then I got:
So, I gave up, and I configured my wrapper to call tp/texi2any.pl
directly from the source directory, by perl interpretation. So it now
works as it did before, there was only the ModulePath.pm module missing
and ./configure has generated it. Yes, it is a bit slow, but never mind.
BTW, I still have this error when texi2any.pl is exectured:
Locales dir for document strings not found (c:/Programmes/installation/texinfo-install/trunk/tp/../tp/maintain/../LocaleData LocaleData ../../../tp/LocaleData ../../tp/LocaleData)
I already had this before the svn update, maybe this is due to using a
non installed version, but running directly from the source directory.
Concerning the bug status: I think there is a bug because whether the
perl installation can use socket or not, and whether one should install
a compiled version or an interpreted version should all be managed by
the configure script, without user intervention. Now, I don't know who
is to blame:
- is that rather an issue of autotools not handling perl module
installation correctly ?
- and is it within autotools to manage perl module
compilation/installation configuration
Most perl module use a Makefile.PL rather than autotools to handle
platform configuration and tool availability, I don't know even whether
tex2any could be distributed on cpan as a standard module if using
autotools rather than perl Automaker.
|